On Sat, Oct 22, 2011 at 22:50, Randall Leeds <randall.le...@gmail.com>wrote:
> > > 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. > Chatting with kocolosk a minute ago I realize my error. "git commit -s" only adds "Signed-Off-By". It is only tags that are GPG signed. > > 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 >
