incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@gbiv.com>
Subject Re: [VOTE] Release Apache OpenOffice 3.4.1 (incubating) RC2
Date Tue, 21 Aug 2012 21:53:58 GMT
On Aug 21, 2012, at 4:59 AM, Branko ─îibej wrote:

> On 21.08.2012 12:52, sebb wrote:
>> I think the NOTICE problems are serious enough to warrant a respin.
> 
> This is an unreasonable request. The IPMC voted on the 3.4.0 release.
> The notice file has not changed between 3.4.0 and 3.4.1. How then do you
> justify this new requirement?

It is his opinion, not a requirement.

> It is not fair to the podling if the IPMC invents new requirements and
> reverses its own decisions for no apparent reason. This NOTICE issue
> certainly shouldn't be ground for vetoing a release.

Nobody can veto a release.  Even the board would require a majority vote,
though root has the power to stop distribution.

> By the way, the same holds for binaries being included in the releases.
> The 3.4.0 release, with binaries, was approved. If the podling did not
> change its release procedures and policies and artefacts in the
> meantime, it's not reasonable to hold up what amounts to a security
> release solely based on the IPMC having screwed up the previous release
> vote.

Of course it is reasonable to expect a podling to read and respect
the release process.  That's the point of doing the release with IPMC
review.

> It is fair to require changes for the next release. It's not fair to use
> different criteria for two successive, essentially identical releases.
> (N.B.: I use the term "essentially identical" in the sense that, whilst
> some of the sources have changed, the overall structure of the release
> artefacts has not.)

Fairness has nothing to do with it.  These issues are all documented

  http://www.apache.org/dev/release.html
  http://www.apache.org/legal/src-headers.html#notice
  http://incubator.apache.org/guides/releasemanagement.html#best-practices-svn

This is not a difficult task, but it does require practice
to get right.  Every RM on every project goes through this pain.

Adherence is necessary to enable peer review.  Peer review
is necessary to enable volunteers to act on behalf of the ASF.
Acting on behalf of the ASF is necessary for legal protection of
the project contributors.  We are teaching the project how to do
an open source release without being held individually liable for
the millions of things that might get one sued for making an
open source release.

Being half-assed about it would not be doing them a favor.

....Roy
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message