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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
