On Sat, Oct 22, 2011 at 18:53, Paul Davis <paul.joseph.da...@gmail.com>wrote:
> On Sat, Oct 22, 2011 at 3:17 PM, Randall Leeds <randall.le...@gmail.com> > wrote: > > On Sat, Oct 22, 2011 at 11:00, Noah Slater <nsla...@tumbolia.org> wrote: > > > >> Jason and Randall, thanks for your dive into the semantic versioning > idea. > >> As you pointed out, CouchDB's use of (as I mentioned previous) the Apple > >> versioning scheme means that it is indistinguishable from the semantic > >> versioning concept. However, I don't buy that we need to be shoehorning > >> "rc1" or "vote1" into the version number so that we can tag it without > >> conflicting with our actual releases. > >> > >> Dustin, thanks for your illuminating response. Some of the things you > >> describe there sound quite interesting, especially the build related > >> automation of release details such as version numbers and changelogs. I > >> guess there might be room for innovation, but that's something I'd like > to > >> look at another time. The Git stuff sounds cool too, though a little > beyond > >> me at this point I will admit. There might be room for improvement in > how > >> we > >> manage our release branches. Perhaps other people, like Paul, want to > weigh > >> in on that? > >> > >> My most pressing concern at the moment is that whatever we decide in > this > >> thread should apply to the whole gamut of Apache projects, in broad > >> strokes. > >> We're actually quite unusual in the fact that we use the GNU Autotools. > >> Most > >> of the other projects use some crazy Java stuff I don't even understand. > >> But > >> we can't attempt anything to fancy here, or anything too specific to our > >> particular set up. > >> > >> On Sat, Oct 22, 2011 at 9:53 AM, Robert Newson <rnew...@apache.org> > wrote: > >> > >> > I'd argue that it is of no interest, after a release, what the release > >> > artifacts looked like in earlier, failed rounds. We can decide, as a > >> > community, that there's value in that but I don't see it. If we go > >> > with reporting the commit id, then you can find them from the mailing > >> > list archives if you want. > >> > > >> > This thread has ranged far and wide but I still think the 'only tag > >> > the release at the end' policy is clear, simple and preferable to the > >> > alternatives proposed so far. > >> > > >> > >> I agree. > >> > > > > Me too. > > > > > >> > >> > >> > As for the fact that 1.2 does not descend from 1.1, this is more than > >> > just a limitation of svn (where a commit can have only one parent). > >> > 1.1.x and 1.2.x (and releases from either) necessarily diverge and so > >> > our source repo should reflect that. > >> > > >> > >> It sounds like Dustin has some interesting ideas on how to manage our > >> back-porting and forward-porting procedures. Managing release branches > has > >> been quite tricky in the past. And if someone with lots of Git-fu wants > to > >> help us manage that process better, I am excited about that. I don't > think > >> this is particularly important for the current discussion though, so is > it > >> best to come back to this later? > >> > >> > >> > Is there a complete alternate proposal to the 'only tag the release at > >> > the end'? Do we feel we're close to finding one? > >> > > >> > >> I don't think so, and I doubt it. > >> > > > > I agree. > > > > > >> > >> > >> > Finally, it seemed obvious to me that the tag would be signed by the > >> > same key that the release manager signs the release artifacts with, so > >> > I was already doing that. I like the idea that the tag should contain > >> > the tally of votes (including the links to the mail archive). I'll do > >> > that for 1.1.1 if no one objects. > >> > > >> > >> +1 to the tag being signed by the same GPG key as the release artefacts. > >> > > > > +1 > > > >> > >> > >> The mailing list already contains the history of the votes, and the > tally > >> of > >> the final round. It should only be necessary to include a reference to > the > >> final vote tally. The rest can be done by whomever it is following the > >> link. > >> I don't think it's necessary to include the release announcement or > >> anything > >> else like that in the tag. Besides, it's important to realise that at > the > >> point the tag is cut, this email hasn't even been sent yet. > >> > >> I would suggest something along the following lines: > >> > >> - > >> > >> Apache CouchDB 1.1.0 was tagged following a successful vote: > >> > >> > >> > http://mail-archives.apache.org/mod_mbox/couchdb-dev/201106.mbox/%3CBANLkTinLheqbrD_=zV0i1ShLEyaD8-L=4...@mail.gmail.com%3E > >> > > > > -1 > > > > ---- > > > > To summarize: > > - It is of no interest to the task of distributing releases, but of > immense > > interest to the community, how a tag came to pass. > > - The primary record of consensus is discussion. > > - The primary references of interest are therefore from discussion to > > artifact. Thus, the mailing archive references commits rather than vice > > versa. > > - Noah just weighed in on the question of what back references to the > > consensus process archive are required to surface on the project git > remote > > simultaneous with the fact of release. I voted -1 on his proposal. > > > > Instead, I propose an alternative scheme, borrowed from the linux kernel > > documentation at [1]: > > > > "If a person has had the opportunity to comment on a patch, but > > has not < > http://www.mjmwired.net/kernel/Documentation/SubmittingPatches#417> > > provided such comments, you may optionally add a "Cc:" tag to the > > patch. < > http://www.mjmwired.net/kernel/Documentation/SubmittingPatches#418> > > This is the only tag which might be added without an explicit > > action by the < > http://www.mjmwired.net/kernel/Documentation/SubmittingPatches#419> > > person it names. This tag documents that potentially interested > > parties < > http://www.mjmwired.net/kernel/Documentation/SubmittingPatches#420> > > have been included in the discussion" > > > > I read the word "opportunity" and "provided" as applying to our > > process as follows: > > - An individual on the mailing list who has cast a vote has had the > > "opportunity" to comment > > - An individual which has not published their own tag on apache > > infrastructure has not, for the purposes of a proper release, > > "provided" their comment.* > > > > Therefore, the release manager should tag and sign with "Cc: Community > > Voter <person@domain>" where person@domain is the email address in the > > archive which is associated with each message casting a vote. > > Upon successfully pushing a release tag, the release manager closes > > voting by replying to the vote thread with the typical notification of > > vote closure and a link to the signed release tag in the project > > remote, along with the archived email messages containing the votes, > > as in our current release procedure.* > > > > This thread is almost there :) > > > > Lastly, we should not allow any commits pushed to Apache > > infrastructure which are not signed off by committers. Looking at our > > nascent git history, we've already broken that, but we should > > discontinue this practice and probably enforce it via infrastructure > > hooks. > > What do you mean? The infra hooks require that all commits are > committed (as opposed to authored) by one of the Apache CouchDB > committers. If that's not true then my infra hooks are busted and need > to be fixed ASAP. > Okay, that's good, but doesn't 100% satisfy my curiosity to explore the issue. > > On the other hand, if you mean that signed-off-by garbage in the > commit message, then I ask, "Why?". The committer that pushed the > commit to the ASF has already implicitly signed off on it. > Is it clear to someone consuming the repository indirectly? Does that matter? Should someone looking at their local copy of the repo be able to verify that the commits in the repository that are attributed to committers were authored by the committers, without knowledge of the full details of how they obtained the clone? It's fair to argue that we're not certifying anything that isn't a release and that the release is signed-off-by the release manager, so it's on the downstream developer/user if they erroneously trust anything but a release. I still favor additional data that assists developers in making judgments about the accountability of what they're seeing before releases. So, do you have a real opinion on the Cc thing? I'm leaning toward dropping it and everything else except Signed-Off-By: Release Manager <releaser@...> for the release tag. Simple. Anything we didn't cover? Is this enough for someone to modify the release procedure wiki page to reflect what we will practise? -Randall
