couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randall Leeds <randall.le...@gmail.com>
Subject Re: Tweaking the release procedure
Date Sun, 23 Oct 2011 21:03:46 GMT
On Sat, Oct 22, 2011 at 22:50, Randall Leeds <randall.leeds@gmail.com>wrote:

>
>
> On Sat, Oct 22, 2011 at 18:53, Paul Davis <paul.joseph.davis@gmail.com>wrote:
>
>> On Sat, Oct 22, 2011 at 3:17 PM, Randall Leeds <randall.leeds@gmail.com>
>> wrote:
>> > On Sat, Oct 22, 2011 at 11:00, Noah Slater <nslater@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 <rnewson@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=4Q@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message