flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Mclean <jus...@classsoftware.com>
Subject Re: The 'less-RC' process explained
Date Tue, 02 Dec 2014 20:41:28 GMT

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.


View raw message