Justin, I don’t think Erik was trying to be so precise with his wording. I think we’re all aware of policy already.
Why don’t you fix any wording you feel is inaccurate? If anyone has issues with your corrections, the wording can be reverted and/or discussed. Thanks, Harbs On Dec 2, 2014, at 10:41 PM, Justin Mclean <jus...@classsoftware.com> wrote: > Hi, > > I'd like to see a few corrections/changes to this process as described. > > Re "packaged and signed by a representative of the organization and voted to > be valid by the contributors of the project." - as per Apache policy anyone > can make a release (but it would be hard if you were not a committer) but > only PMC votes are binding on releases, committers or other contributors can > vote but their votes are not binding. > > RE "the voting process is repeated until no new blocking issues are found in > the artifacts." it actually repeated until there 3+1 votes and more +1s than > -1s. A release may include something that someone considers a blocker, if it > gets enough +!s. > > RE "As soon as someone finds a blocking issue, the entire process stops." > This is not normally the case, and in fact has been the cause of excessive RC > in the past, you would want to PMC to continue to check the release for other > issues even f there is a blocker, and again one persons "blocker" (ie > spelling issues) may not be anothers, consensus (while nice to have) is not > required for releases. We have had a couple of releases that passed with -1s. > > RE "The issue if fixed or the issue is discussed until consensus is reached." > this is against Apache release policy. Consensus is not required for releases. > > RE "Any issues found should be fixed - preferably by the reporter " it not > always going to be possible that the person who reports the issue can fix it. > > I'd also note that this was basically the process we took for TourDeFlex but > it resulted in having 3 release candidates. > > Thanks, > Justin > >
