On 02/03/2012 12:01 PM, Ross Gardler wrote:
On 3 February 2012 10:47, Ate Douma<[email protected]> wrote:
On 02/03/2012 11:00 AM, Ross Gardler wrote:
No need for a vote on this, we agreed the outstanding items weren't
blockers. Just go ahead and do it under lazy consenus (remember a
release cannot be vetoed so your time will not be wasted, even if
someone missed the issues thread)
True.
On the other hand, I'd like to check with you if at least the NOTICE and
LICENSE requirements are properly (or at least good enough) been validated
before you create the tag. If there are serious issues with those, *that*
could result in a blocking -1 vote, either here or else on the final vote on
general@incubator.
Absolutely, but I assumed that we would be asked to review the release
before voting on it. I thought the process was:
1) agree it's time to do a release
2) prepare the build src
3) ask for a review of the src (e.g. license headers, notice files etc.)
4) build once we are happy
5) vote on the release
From Ate's mail above it appears that Ate felt this vote was for step
3 whereas I thought it was for step 1.
Either way I don't want two votes per release. We should just be
voting on step 5) and that should really be a formality since step 3)
is where the actual review happens. Step 5) is just making sure the
build is from the same src, is signed correctly etc.
Seems we need more clarity in what stage Paul thinks he is at.
My question then is: what is the plan to do 2)
If 2) means creating a separate release candidate branch (e.g. 0.9.2-rc1) and
then review (and possibly fix) that, so that 4) results in creating the release
tag 0.9.2 from the branch, I'm OK.
What I would not prefer though is creating a release tag 0.9.2 for 2) and then
commit fixes against that tag. Although technically this is not a problem,
committing changes against a release tag is considered 'bad practice'.
The general view is that once you create a release tag you'd kind of give up
reusing/changing it afterwards.
And it thus also means if a release blocker comes up afterwards, you've 'lost'
that release version, e.g. you then should move on to creating a new 0.9.3
release tag instead of start 'fixing' 0.9.2.
This isn't a hard rule though, it really depends on the policy Wookie PMC should
determine for itself it wants to follow. The above simply is a 'best practice'
used by almost all projects in the ASF.
Exception cases have discussed recently in the Incubator PMC, like accepting
minor changes for (only?) LICENSE/NOTICE files which do not affect the tarball
itself (technically). Although that primarily concerned the question if such
minor changes should require a full rewind of the release itself (including
having to wait another minimal 72 hours before acceptance).
How that fits or conflicts with a policy of 'tags should not be modified' I
haven't seen any discussion about though.
Ate
Ross
