Hi, On Dec 27, 2007 8:39 AM, <[EMAIL PROTECTED]> wrote: > > We can't be voting on a release and then have changes made to it > > before it goes out. The vote needs to happen on the actual bytes that > > we will be publishing. > > I disagree with you on this Jukka -- there's a difference between > updating text in a CHANGES.txt file that affects nothing, and updating > source code.
Changing anything in the release package affects at least the checksums and signatures, and verifying them is an important part of the audit associated with the release vote. > Additionally, it wouldn't be updating a tag (which is > suppossed to be "sacred"), it would be updating a branch (which > inherently can be modified). That's why branch first, tag later, is a > good practice. So, as you'll see below, because I *branched* and > didn't *tag*, it's perfectly OK to update the branch (e.g., with the > new CHANGES.txt file), and then create a new RC from it. I suggest > doing this as a compromise. Certainly. How the release is handled in svn is not that essential, and there's no requirement of even having any branches or tags for a releases. The stuff that's really important for the release vote is the packaged release candidate, so repackaging and calling a new vote on the new RC is quite OK even without any svn activity (though making the changes go through svn would certainly be good). > > I suggest we make the suggested changes, tag and package the modified > > release candidate, and restart the vote in a "[VOTE]" thread (it's > > good practice to use that subject tag to make the vote threads easier > > to filter and find). > > I could go both ways on this. I'm not sure that we need a brand new > vote thread just to have a new message header, and a few nominal > changes, however, if you feel strongly about it, I am willing to bend. I think it's better to start a new vote thread. It doesn't cost much and keeps things nice and clear by avoiding potential confusion about what we really are voting on. The purpose of the release vote is to make the release an action (and thus a liability) of the ASF instead of the individual release manager. It's best not to muddy those waters even for "nominal changes" as later on (say a few years down the line) it'll be quite difficult to determine what those changes really were, and whether the the release vote really did imply that the ASF should embrace also the modified release. Sure, this is probably a rather academic concern for Tika at this stage, but it's better to get the process straight right at the beginning instead of later on when the audience of our releases will likely be higher. > I'm not sure there's *only* one right way to do this. +1 There's quite a lot of freedom for a project and a release manager to decide what best suits them. What I'm concerned about is that we don't have a release vote on something that still gets modified before it gets published. > Yes, let's make an update to the 0.1 branch. I see that you've already > made a few changes. I will go ahead and update CHANGES.txt there as > well, create a new release candidate, and then call for a new vote. > Sound good? Yes, thanks! While you're at it, please also include your key in the KEYS file and and post the file along with the release candidate. BR, Jukka Zitting
