Tweaking the release procedure

[Paul Davis <pa...@gmail.com>]

Devs,

Now that we're on Git and have a system for managing tags that isn't
nutty, its time that we should revisit our tagging protocol for
releases.

First, a note about the Git hosting. One of the ASF requests was that
I write a thing that prevented the ability of rewriting history on
master. When I implemented this I made the branch pattern configurable
to multiple branches. Currently this protection applies to master,
trunk, and any branch or tag prefixed with "rel/". The idea was that
we'd be able to move release branches like 1.1.x, 1.2.x etc to
rel/1.1.x and rel/1.2.x so that we don't accidentally break them. The
same for tags. Once we tag something as rel/1.1.1 the rewrite checks
will prevent someone from accidentally modifying it.

So given that, and the fact that Git lets us alias specific tags
exactly, I thought I'd propose a couple slight tweaks to the release
procedure.

1. When tagging release candidates, the tag would be of the pattern:

     tags/rc/X.Y.Z-rcN

2. When a release formally passes a vote, we would copy the tag to:

     tags/rel/X.Y.Z

3. I think we discussed this before, but we should also place the rc
artefacts into a directory named as such (IIRC, we decided that the
name shouldn't change). Ie, 1.1.1 would be stored at:
http://people.apache.org/~rnewson/dist/1.1.1/rc1/apache-couchdb-1.1.1.tar.gz

4. Making new release branches we should name them:

    branches/rel/X.Y.x

5. For continuity, I'd also propose copying all of our older tags and
branches to the new pattern (while keeping the current versions around
for an extended period of time).

Thoughts?

Re: Tweaking the release procedure

[Paul Davis <pa...@gmail.com>]

On Wed, Oct 19, 2011 at 12:28 PM, Adam Kocoloski <ko...@apache.org> wrote:
> Paul, +1 to the broad strokes, but I'm a little confused about the specifics.  Do you really want branch names to start with "branches/" and tag names to start with "tags/"?  Or is that just a bit of abstraction leakage from the git internals?
>

Sorry, yeah. Before I had those it was a bit confusing between
"rel/1.1.1" and "rel/1.1.x" where one is actually an internal name of
"refs/tags/rel/1.1.1" and the other is "refs/branches/rel/1.1.x". Just
wanted to make that more apparent.

> Branch names like rel/1.1.x for non-rewriteable release branches are fine by me.  Tags like rc/1.1.1rc1 and rel/1.1.1 I'm not so excited about.  Are you trying to use those prefixes to enforce that the tags are immutable?  If so, then I guess it makes sense, though maybe we don't need to repeat ourselves and instead use rc/1.1.1-1.
>

Well, the rel/ prefix is for the pattern match to enforce the
non-rewriting part. The rc/ is just convention and would  be
rewritable. Or we could just disallow rewriting of any tag and then
have "1.1.1-rc1" "1.1.1-rc2" "1.1.1" etc etc. I don't have a huge
investment in the rel/ prefix by any means. Was just considering that
we have the capability so wondering if people would want to use it.

> Bob, I think it's a good thing that copying the accepted release candidate to the final release tag preserves the relationship between the two things.  I don't find it off-putting at all.
>

+1

> Thanks for getting this discussion going guys.
>
> Adam
>
> On Oct 19, 2011, at 1:11 PM, Robert Newson wrote:
>
>> I like it, +1.
>>
>> I'll note that the copied tag '1.1.1' from '1.1.1rc1' will look a
>> little strange. It will be exactly the same as the '1.1.1rc1' tag,
>> including *saying* 'tag 1.1.1rc1' in the tag body (when you view it
>> with git tag -v 1.1.1, for example). I'm fine with that, it's pointing
>> at the same stuff and it's a record of the fact that rc1 was blessed
>> as the actual release, but I mention it because it's odd.
>>
>> B.
>>
>> On 19 October 2011 17:55, Paul Davis <pa...@gmail.com> wrote:
>>> Devs,
>>>
>>> Now that we're on Git and have a system for managing tags that isn't
>>> nutty, its time that we should revisit our tagging protocol for
>>> releases.
>>>
>>> First, a note about the Git hosting. One of the ASF requests was that
>>> I write a thing that prevented the ability of rewriting history on
>>> master. When I implemented this I made the branch pattern configurable
>>> to multiple branches. Currently this protection applies to master,
>>> trunk, and any branch or tag prefixed with "rel/". The idea was that
>>> we'd be able to move release branches like 1.1.x, 1.2.x etc to
>>> rel/1.1.x and rel/1.2.x so that we don't accidentally break them. The
>>> same for tags. Once we tag something as rel/1.1.1 the rewrite checks
>>> will prevent someone from accidentally modifying it.
>>>
>>> So given that, and the fact that Git lets us alias specific tags
>>> exactly, I thought I'd propose a couple slight tweaks to the release
>>> procedure.
>>>
>>> 1. When tagging release candidates, the tag would be of the pattern:
>>>
>>>     tags/rc/X.Y.Z-rcN
>>>
>>> 2. When a release formally passes a vote, we would copy the tag to:
>>>
>>>     tags/rel/X.Y.Z
>>>
>>> 3. I think we discussed this before, but we should also place the rc
>>> artefacts into a directory named as such (IIRC, we decided that the
>>> name shouldn't change). Ie, 1.1.1 would be stored at:
>>> http://people.apache.org/~rnewson/dist/1.1.1/rc1/apache-couchdb-1.1.1.tar.gz
>>>
>>> 4. Making new release branches we should name them:
>>>
>>>    branches/rel/X.Y.x
>>>
>>> 5. For continuity, I'd also propose copying all of our older tags and
>>> branches to the new pattern (while keeping the current versions around
>>> for an extended period of time).
>>>
>>> Thoughts?
>>>
>
>

Re: Tweaking the release procedure

[Adam Kocoloski <ko...@apache.org>]

Paul, +1 to the broad strokes, but I'm a little confused about the specifics.  Do you really want branch names to start with "branches/" and tag names to start with "tags/"?  Or is that just a bit of abstraction leakage from the git internals?

Branch names like rel/1.1.x for non-rewriteable release branches are fine by me.  Tags like rc/1.1.1rc1 and rel/1.1.1 I'm not so excited about.  Are you trying to use those prefixes to enforce that the tags are immutable?  If so, then I guess it makes sense, though maybe we don't need to repeat ourselves and instead use rc/1.1.1-1.

Bob, I think it's a good thing that copying the accepted release candidate to the final release tag preserves the relationship between the two things.  I don't find it off-putting at all.

Thanks for getting this discussion going guys.

Adam

On Oct 19, 2011, at 1:11 PM, Robert Newson wrote:

> I like it, +1.
> 
> I'll note that the copied tag '1.1.1' from '1.1.1rc1' will look a
> little strange. It will be exactly the same as the '1.1.1rc1' tag,
> including *saying* 'tag 1.1.1rc1' in the tag body (when you view it
> with git tag -v 1.1.1, for example). I'm fine with that, it's pointing
> at the same stuff and it's a record of the fact that rc1 was blessed
> as the actual release, but I mention it because it's odd.
> 
> B.
> 
> On 19 October 2011 17:55, Paul Davis <pa...@gmail.com> wrote:
>> Devs,
>> 
>> Now that we're on Git and have a system for managing tags that isn't
>> nutty, its time that we should revisit our tagging protocol for
>> releases.
>> 
>> First, a note about the Git hosting. One of the ASF requests was that
>> I write a thing that prevented the ability of rewriting history on
>> master. When I implemented this I made the branch pattern configurable
>> to multiple branches. Currently this protection applies to master,
>> trunk, and any branch or tag prefixed with "rel/". The idea was that
>> we'd be able to move release branches like 1.1.x, 1.2.x etc to
>> rel/1.1.x and rel/1.2.x so that we don't accidentally break them. The
>> same for tags. Once we tag something as rel/1.1.1 the rewrite checks
>> will prevent someone from accidentally modifying it.
>> 
>> So given that, and the fact that Git lets us alias specific tags
>> exactly, I thought I'd propose a couple slight tweaks to the release
>> procedure.
>> 
>> 1. When tagging release candidates, the tag would be of the pattern:
>> 
>>     tags/rc/X.Y.Z-rcN
>> 
>> 2. When a release formally passes a vote, we would copy the tag to:
>> 
>>     tags/rel/X.Y.Z
>> 
>> 3. I think we discussed this before, but we should also place the rc
>> artefacts into a directory named as such (IIRC, we decided that the
>> name shouldn't change). Ie, 1.1.1 would be stored at:
>> http://people.apache.org/~rnewson/dist/1.1.1/rc1/apache-couchdb-1.1.1.tar.gz
>> 
>> 4. Making new release branches we should name them:
>> 
>>    branches/rel/X.Y.x
>> 
>> 5. For continuity, I'd also propose copying all of our older tags and
>> branches to the new pattern (while keeping the current versions around
>> for an extended period of time).
>> 
>> Thoughts?
>> 

Re: Tweaking the release procedure

[Paul Davis <pa...@gmail.com>]

I'd say its fine. As you point out it's just that we blessed the rc1.
I'm guessing that's impossible to change given the GPG signature.

On Wed, Oct 19, 2011 at 12:11 PM, Robert Newson <rn...@apache.org> wrote:
> I like it, +1.
>
> I'll note that the copied tag '1.1.1' from '1.1.1rc1' will look a
> little strange. It will be exactly the same as the '1.1.1rc1' tag,
> including *saying* 'tag 1.1.1rc1' in the tag body (when you view it
> with git tag -v 1.1.1, for example). I'm fine with that, it's pointing
> at the same stuff and it's a record of the fact that rc1 was blessed
> as the actual release, but I mention it because it's odd.
>
> B.
>
> On 19 October 2011 17:55, Paul Davis <pa...@gmail.com> wrote:
>> Devs,
>>
>> Now that we're on Git and have a system for managing tags that isn't
>> nutty, its time that we should revisit our tagging protocol for
>> releases.
>>
>> First, a note about the Git hosting. One of the ASF requests was that
>> I write a thing that prevented the ability of rewriting history on
>> master. When I implemented this I made the branch pattern configurable
>> to multiple branches. Currently this protection applies to master,
>> trunk, and any branch or tag prefixed with "rel/". The idea was that
>> we'd be able to move release branches like 1.1.x, 1.2.x etc to
>> rel/1.1.x and rel/1.2.x so that we don't accidentally break them. The
>> same for tags. Once we tag something as rel/1.1.1 the rewrite checks
>> will prevent someone from accidentally modifying it.
>>
>> So given that, and the fact that Git lets us alias specific tags
>> exactly, I thought I'd propose a couple slight tweaks to the release
>> procedure.
>>
>> 1. When tagging release candidates, the tag would be of the pattern:
>>
>>     tags/rc/X.Y.Z-rcN
>>
>> 2. When a release formally passes a vote, we would copy the tag to:
>>
>>     tags/rel/X.Y.Z
>>
>> 3. I think we discussed this before, but we should also place the rc
>> artefacts into a directory named as such (IIRC, we decided that the
>> name shouldn't change). Ie, 1.1.1 would be stored at:
>> http://people.apache.org/~rnewson/dist/1.1.1/rc1/apache-couchdb-1.1.1.tar.gz
>>
>> 4. Making new release branches we should name them:
>>
>>    branches/rel/X.Y.x
>>
>> 5. For continuity, I'd also propose copying all of our older tags and
>> branches to the new pattern (while keeping the current versions around
>> for an extended period of time).
>>
>> Thoughts?
>>
>

Re: Tweaking the release procedure

[Robert Newson <rn...@apache.org>]

I like it, +1.

I'll note that the copied tag '1.1.1' from '1.1.1rc1' will look a
little strange. It will be exactly the same as the '1.1.1rc1' tag,
including *saying* 'tag 1.1.1rc1' in the tag body (when you view it
with git tag -v 1.1.1, for example). I'm fine with that, it's pointing
at the same stuff and it's a record of the fact that rc1 was blessed
as the actual release, but I mention it because it's odd.

B.

On 19 October 2011 17:55, Paul Davis <pa...@gmail.com> wrote:
> Devs,
>
> Now that we're on Git and have a system for managing tags that isn't
> nutty, its time that we should revisit our tagging protocol for
> releases.
>
> First, a note about the Git hosting. One of the ASF requests was that
> I write a thing that prevented the ability of rewriting history on
> master. When I implemented this I made the branch pattern configurable
> to multiple branches. Currently this protection applies to master,
> trunk, and any branch or tag prefixed with "rel/". The idea was that
> we'd be able to move release branches like 1.1.x, 1.2.x etc to
> rel/1.1.x and rel/1.2.x so that we don't accidentally break them. The
> same for tags. Once we tag something as rel/1.1.1 the rewrite checks
> will prevent someone from accidentally modifying it.
>
> So given that, and the fact that Git lets us alias specific tags
> exactly, I thought I'd propose a couple slight tweaks to the release
> procedure.
>
> 1. When tagging release candidates, the tag would be of the pattern:
>
>     tags/rc/X.Y.Z-rcN
>
> 2. When a release formally passes a vote, we would copy the tag to:
>
>     tags/rel/X.Y.Z
>
> 3. I think we discussed this before, but we should also place the rc
> artefacts into a directory named as such (IIRC, we decided that the
> name shouldn't change). Ie, 1.1.1 would be stored at:
> http://people.apache.org/~rnewson/dist/1.1.1/rc1/apache-couchdb-1.1.1.tar.gz
>
> 4. Making new release branches we should name them:
>
>    branches/rel/X.Y.x
>
> 5. For continuity, I'd also propose copying all of our older tags and
> branches to the new pattern (while keeping the current versions around
> for an extended period of time).
>
> Thoughts?
>

Re: Tweaking the release procedure

[Paul Davis <pa...@gmail.com>]

On Thu, Oct 20, 2011 at 8:23 PM, Noah Slater <ns...@tumbolia.org> wrote:
> On Fri, Oct 21, 2011 at 2:04 AM, Dustin Sallings <du...@spy.net> wrote:
>
> In the above example, if someone downloaded and is currently running
>> 1.1.1-rc1 and he looks at the list of tags and sees v1.1.1, v1.1.1-rc1 and
>> v1.1.1-rc2, why would be confused?  More importantly, you released that, so
>> why would you not want the user to be able to see whether any changes
>> between 1.1.1-rc1 and 1.1.1 final affect his deployment?
>
>
> If someone has downloaded and is running an artefact from a botched release
> vote, our release procedure has failed us catastrophically. Nobody should
> EVER be running these as-of-yet-not-approved release artefacts. Except for
> testing and voting, obviously. Hence, the only reason you'd want to see what
> the changes were between 1.1.1-rc1 and 1.1.1 would be for testing a second
> round of voting. Perhaps we should eschew the "release candidate"
> nomenclature if it is causing these problems? I am worried that we might be
> sending the wrong message to our users who expect this terminology to mean
> something else entirely. Oh, and Sorry about replying in
> a piecemeal fashion!
>

Piecemeal helps us find our way back.

http://en.wikipedia.org/wiki/Hansel_and_Gretel

Re: Tweaking the release procedure

[Noah Slater <ns...@tumbolia.org>]

On Fri, Oct 21, 2011 at 2:04 AM, Dustin Sallings <du...@spy.net> wrote:

In the above example, if someone downloaded and is currently running
> 1.1.1-rc1 and he looks at the list of tags and sees v1.1.1, v1.1.1-rc1 and
> v1.1.1-rc2, why would be confused?  More importantly, you released that, so
> why would you not want the user to be able to see whether any changes
> between 1.1.1-rc1 and 1.1.1 final affect his deployment?


If someone has downloaded and is running an artefact from a botched release
vote, our release procedure has failed us catastrophically. Nobody should
EVER be running these as-of-yet-not-approved release artefacts. Except for
testing and voting, obviously. Hence, the only reason you'd want to see what
the changes were between 1.1.1-rc1 and 1.1.1 would be for testing a second
round of voting. Perhaps we should eschew the "release candidate"
nomenclature if it is causing these problems? I am worried that we might be
sending the wrong message to our users who expect this terminology to mean
something else entirely. Oh, and Sorry about replying in
a piecemeal fashion!

Re: Tweaking the release procedure

[Adam Kocoloski <ko...@apache.org>]

Sorry for the self-reply, but I read the thread of Bob's comment and I see that he dismissed my concern as irrelevant.  Well, fine then :)  If you want to solve this by fiat and say that users are not allowed to rely on their local copies of our signed tags as authoritative then these debates are a waste of time.  Best,

Adam

On Oct 21, 2011, at 3:26 PM, Adam Kocoloski wrote:

> Hmmm ... that's all well and good, but I envision more confusion ensuing in the case where we have multiple possible values for '1.1.1' floating around the internet than I do in the case where we have '1.1.1-rc1', '1.1.1-rc2', and eventually one single immutable '1.1.1'.  Best,
> 
> Adam
> 
> On Oct 21, 2011, at 2:29 PM, Robert Newson wrote:
> 
>> From the other thread, reposted here on Noah's suggestion;
>> 
>> My take on tagging was to follow what we did with SVN with only minor
>> changes to account for git. So I shall describe it.
>> 
>> First, I create a signed tag for the release, with its intended final
>> release value. In this case, exactly the string '1.1.1'. Then I build
>> artifacts from the tag (which could be from a 'git archive 1.1.1' or
>> 'git checkout 1.1.1 && git clean -xdfq'). When I'm happy with the
>> output of that phase (i.e, I've done the diff -r, make check, Futon,
>> etc from the generated tar.gz) I upload it to people.apache.org and
>> push the tag (so that others can verify that it matches the release
>> artifact).
>> 
>> In the event of a round veto, I delete the 1.1.1 tag. In the next
>> round, I create and push a new signed 1.1.1 tag as part of the same
>> procedure.
>> 
>> 'git pull --tags' correctly updates anyone's existing (but now wrong)
>> 1.1.1 tag (the man page for git-tag goes on at some length that it
>> doesn't do that and how evil such a thing would be, but it does it
>> anyway).
>> 
>> The arguments in the other thread about immutable tags are laudable
>> but irrelevant. The tags in our source control system are not the
>> source of truth for our releases. The presence of the release on the
>> Apache mirrors is. The entire discussion around -rcX suffixes is to
>> avoid any confusion between the failed artifacts and the release
>> artifact. While a genuine concern, it's not worth all this soul
>> searching in my opinion. The real 1.1.1 comes from the mirrors. When
>> it's available on our mirrors then it also means that the 1.1.1 tag in
>> source control points to it (and always will).
>> 
>> B.
>> 
>> On 21 October 2011 19:25, Robert Newson <ro...@gmail.com> wrote:
>>> Dustin,
>>> 
>>> 
>>> /tmp/bar $ git --version
>>> git version 1.7.6.1
>>> 
>>> /tmp/bar $ git pull --tags
>>> remote: Counting objects: 4, done.
>>> remote: Compressing objects: 100% (2/2), done.
>>> remote: Total 3 (delta 0), reused 0 (delta 0)
>>> Unpacking objects: 100% (3/3), done.
>>> From /tmp/foo
>>> - [tag update]      1.0        -> 1.0
>>> Fetching tags only, you probably meant:
>>> git fetch --tags
>>> 
>>> The 1.0 tag was correctly updated.
>>> 
>>> B.
>>> 
>>> On 21 October 2011 19:11, Noah Slater <ns...@tumbolia.org> wrote:
>>>> On Fri, Oct 21, 2011 at 7:04 PM, Dustin Sallings <du...@spy.net> wrote:
>>>> 
>>>> IMO, simplicity and conventions win here.  Tags should be treated as
>>>>> immutable pointers to commits that had some meaning and should be named and
>>>>> labeled meaningfully as well.  Branches are pointers to works in progress.
>>>>> When work is "finished", they can be tagged and deleted.  If you do this,
>>>>> all of the defaults work and you don't have to invent and document as much.
>>>>> 
>>>> 
>>>> The only way I can see this working then is to "move" the tag once a vote
>>>> passes. Whether this involves duplicating the tag, or creating a new one
>>>> that points to the same thing, I don't know. Other people with more Git-fu
>>>> can step in here. But we need a way of blessing tags that works with
>>>> downstream repositories, and that separates them out from defunct tags that
>>>> never made the cut.
>>>> 
>>> 
> 

Re: Tweaking the release procedure

[Robert Newson <rn...@apache.org>]

Great minds, etc.

On 21 October 2011 22:50, Dave Cottlehuber <da...@muse.net.nz> wrote:
> On 21 October 2011 23:47, Dave Cottlehuber <da...@muse.net.nz> wrote:
>> My 2c;
>> * This is a long-lived project. At 3+ releases/year + votes this will
>> over time get quite long. Some cleaning would be good.
>
> Sorry this wasn't correct. I'm not proposing any git rewriting, rather
> that adding tags for every RC/whatever will become untidy in the long
> term.
>
> A+D
>

Re: Tweaking the release procedure

[Dave Cottlehuber <da...@muse.net.nz>]

On 21 October 2011 23:47, Dave Cottlehuber <da...@muse.net.nz> wrote:
> My 2c;
> * This is a long-lived project. At 3+ releases/year + votes this will
> over time get quite long. Some cleaning would be good.

Sorry this wasn't correct. I'm not proposing any git rewriting, rather
that adding tags for every RC/whatever will become untidy in the long
term.

A+D

Re: Tweaking the release procedure

[Dave Cottlehuber <da...@muse.net.nz>]

On 21 October 2011 22:20, Dustin Sallings <du...@spy.net> wrote:
>
> On Oct 21, 2011, at 12:57 PM, Noah Slater wrote:
>
>> It sounds trivial, but I think it's important to namespace these instead of
>> using suffixes.
>
>
>        The only practical difference is the grep you use when looking for stuff, IMO.  I think it will be unambiguous, but a bit less consistent with other uses of tags in git projects.  At one point, there was a bug in some git commands involving tags with slashes in the name (akin to spaces in filenames kinds of bugs).  I'm pretty sure they've all been fixed.
>
>        The de-facto standard (i.e. the thing people would be looking for) is to prefix release tags with a "v".  e.g. "v1.1.1"
>
>> We'd then copy this to the "release/1.1.1" tag in Git once the vote passed.
>
>        I don't quite understand this language.  Tags aren't copied, they're just created.  You can have as many tags as you want pointing to the same location.
>
>> The ASF suggests (as does Jukka in this thread) that nothing be required of the source code once the vote passes.
>
>        Does this just mean you don't want to have the tree self-identify based on the latest tag pointing to it? Unlike subversion, the *exact* code is used when accessing a tag.
>
>        Example:
>
>        vote-1.1.1-3
>                Tagger name, date
>                message ("let's vote again on 1.1.1!")
>                commit with hash 23c95e52bd01542f803986aa7234980a70d655a4
>
>        v1.1.1
>                Tagger name, date
>                message ("CouchDB 1.1.1 Release\n[lots of release notes]")
>                commit with hash 23c95e52bd01542f803986aa7234980a70d655a4
>
>        commit with hash 23c95e52bd01542f803986aa7234980a70d655a4
>                Author name, date
>                Committer name, date
>                Description
>                Parent pointer(s)
>
>                tree with hash bc4e6b426f8004a0e0b486f6c5ea610bb2026688
>
>        It's cryptographically provable that nothing changes between those two tags (though I'd definitely write up a fresh set of release notes to store within that new tag).
>
>> vote/1.2.2/2
>> vote/1.2.2/3
>> release/1.1.1
>> release/1.2.0
>
> vs.
>
>> 1.2.1-vote2
>> 1.2.2
>> 1.2.2-vote1
>> 1.2.2-vote2
>
>> I think there is a much clearer separation of concerns in the first example.
>
>
>        It looks like you're mostly concerned about the default sorting order of the full tag list command.  I don't think it's a huge deal either way.
>
>        I'm around +0.9 on this since ambiguity goes away, but still seems that doing a more "standard" release tag is good idea since that's the most clear.
>
> --
> dustin sallings
>
>
>
>

I'm hopefully just summarising what people have said in a non-tech
way, so us simple folk have it clear:

* First and foremost we have to ensure there's no confusion between
the release in the version control system, the named vote tarball(s)
on both people.a.o and the official couchdb.a.o/.... download
tarballs. This saves devs, users and packagers grief.
* Our official releases are the tarball on couchdb.a.o.
* Lots of folk build from git/svn anyway using the tag or branch.
There is an incorrect expectation that these are immutable.
* Namespacing git tags seems like it keeps things tidy and also makes
svn users feel at home.
* Much of the apache release process is around ensuring integrity of
releases. git provides a fair bit of that directly as Dustin's pointed
out.

My 2c;
* Requiring a less-well known git command to sync repos correctly
seems risky. [git --pull --tags]. If that functionality in git does
*not* match the documentation this seems foolish.
* This is a long-lived project. At 3+ releases/year + votes this will
over time get quite long. Some cleaning would be good.

What if we refer to RCs simply by git hash, and then *only* tag the
final agreed release? I know we've got to have the release version
hardcoded (e.g. in GET / and at startup in the erl shell), so this
would need to read the version # already to avoid the release
artefacts needing to be changed post vote. Is this workable?

A+
Dave

Re: Tweaking the release procedure

[Dustin Sallings <du...@spy.net>]

On Oct 21, 2011, at 12:57 PM, Noah Slater wrote:

> It sounds trivial, but I think it's important to namespace these instead of
> using suffixes.


	The only practical difference is the grep you use when looking for stuff, IMO.  I think it will be unambiguous, but a bit less consistent with other uses of tags in git projects.  At one point, there was a bug in some git commands involving tags with slashes in the name (akin to spaces in filenames kinds of bugs).  I'm pretty sure they've all been fixed.

	The de-facto standard (i.e. the thing people would be looking for) is to prefix release tags with a "v".  e.g. "v1.1.1"

> We'd then copy this to the "release/1.1.1" tag in Git once the vote passed.

	I don't quite understand this language.  Tags aren't copied, they're just created.  You can have as many tags as you want pointing to the same location.

> The ASF suggests (as does Jukka in this thread) that nothing be required of the source code once the vote passes. 

	Does this just mean you don't want to have the tree self-identify based on the latest tag pointing to it? Unlike subversion, the *exact* code is used when accessing a tag.

	Example:

	vote-1.1.1-3
		Tagger name, date
		message ("let's vote again on 1.1.1!")
		commit with hash 23c95e52bd01542f803986aa7234980a70d655a4

	v1.1.1
		Tagger name, date
		message ("CouchDB 1.1.1 Release\n[lots of release notes]")
		commit with hash 23c95e52bd01542f803986aa7234980a70d655a4

	commit with hash 23c95e52bd01542f803986aa7234980a70d655a4
		Author name, date
		Committer name, date
		Description
		Parent pointer(s)

		tree with hash bc4e6b426f8004a0e0b486f6c5ea610bb2026688

	It's cryptographically provable that nothing changes between those two tags (though I'd definitely write up a fresh set of release notes to store within that new tag).

> vote/1.2.2/2
> vote/1.2.2/3
> release/1.1.1
> release/1.2.0

vs.

> 1.2.1-vote2
> 1.2.2
> 1.2.2-vote1
> 1.2.2-vote2

> I think there is a much clearer separation of concerns in the first example.


	It looks like you're mostly concerned about the default sorting order of the full tag list command.  I don't think it's a huge deal either way.

	I'm around +0.9 on this since ambiguity goes away, but still seems that doing a more "standard" release tag is good idea since that's the most clear.

-- 
dustin sallings

Re: Tweaking the release procedure

[Jan Lehnardt <ja...@apache.org>]

On Oct 21, 2011, at 21:57 , Noah Slater wrote:

> On Fri, Oct 21, 2011 at 8:54 PM, Adam Kocoloski <ko...@apache.org> wrote:
> 
> 
>> Good suggestion on the -vote1 suffix instead of -rc1.  Gets my vote.  Best,
>> 
> 
> It sounds trivial, but I think it's important to namespace these instead of
> using suffixes.

I was merely suggesting to use vote instead of RC, where that is applied (namespace/suffix/wherever) I don't feel strongly about. If your last proposal makes sense to Dustin, that sounds good to me :)

Cheers
Jan
-- 

Re: Tweaking the release procedure

[Noah Slater <ns...@tumbolia.org>]

On Fri, Oct 21, 2011 at 8:57 PM, Noah Slater <ns...@tumbolia.org> wrote:

>
> On Fri, Oct 21, 2011 at 8:54 PM, Adam Kocoloski <ko...@apache.org>wrote:
>
>
>> Good suggestion on the -vote1 suffix instead of -rc1.  Gets my vote.
>>  Best,
>>
>
> It sounds trivial, but I think it's important to namespace these instead of
> using suffixes.
>

It might be good to get the NS matched up to the dist/ structure.

How about:

vote/X.Y.Z/n maps to dist/X.Y.Z/n

Where n is the round number.

So, taking the next round of voting on 1.1.1, we would have:

    http://people.apache.org/~rnewson/dist/1.1.1/3

And this would be built from the "vote/1.1.1/3" tag in Git.

We'd then copy this to the "release/1.1.1" tag in Git once the vote passed.

As far as I can see, this solves all of the problems identified so far
except one. The ASF suggests (as does Jukka in this thread) that nothing be
required of the source code once the vote passes. I don't think we can
satisfy this requirement. But how important that is depends on what the
reasoning for the request is. If it is about making sure that you have an
absolute pointer to the code that was used to build the release artefacts,
does a re-tag as described above satisfy that constraint from a technical
perspective? See what I'm getting at?

Re: Tweaking the release procedure

[Adam Kocoloski <ko...@apache.org>]

On Oct 21, 2011, at 4:07 PM, Noah Slater wrote:

> On Fri, Oct 21, 2011 at 9:03 PM, Adam Kocoloski <ko...@apache.org> wrote:
> 
> Sure, that works.  It makes little difference to me.  Why do you think it's
>> important?
> 
> 
> It's important for the list of tags people see in the repository.
> 
> Compare:
> 
> vote/1.1.1/1
> vote/1.1.1/2
> vote/1.1.1/3
> vote/1.2.0/1
> vote/1.2.0/2
> vote/1.2.1/1
> vote/1.2.2/1
> vote/1.2.2/2
> vote/1.2.2/3
> release/1.1.1
> release/1.2.0
> release/1.2.1
> release/1.2.2
> 
> With:
> 
> 1.1.1
> 1.1.1-vote1
> 1.1.1-vote2
> 1.1.1-vote3
> 1.2.0
> 1.2.0-vote1
> 1.2.1
> 1.2.1-vote1
> 1.2.1-vote2
> 1.2.2
> 1.2.2-vote1
> 1.2.2-vote2
> 1.2.2-vote3
> 
> I think there is a much clearer separation of concerns in the first example.
> 
> My goal is to keep our voting artefacts as far away from our release
> artefacts as possible.

Ok, I was wondering if you had something else in mind.  I don't see much possibility for confusion either way.

Re: Tweaking the release procedure

[Noah Slater <ns...@tumbolia.org>]

On Fri, Oct 21, 2011 at 9:03 PM, Adam Kocoloski <ko...@apache.org> wrote:

Sure, that works.  It makes little difference to me.  Why do you think it's
> important?


It's important for the list of tags people see in the repository.

Compare:

vote/1.1.1/1
vote/1.1.1/2
vote/1.1.1/3
vote/1.2.0/1
vote/1.2.0/2
vote/1.2.1/1
vote/1.2.2/1
vote/1.2.2/2
vote/1.2.2/3
release/1.1.1
release/1.2.0
release/1.2.1
release/1.2.2

With:

1.1.1
1.1.1-vote1
1.1.1-vote2
1.1.1-vote3
1.2.0
1.2.0-vote1
1.2.1
1.2.1-vote1
1.2.1-vote2
1.2.2
1.2.2-vote1
1.2.2-vote2
1.2.2-vote3

I think there is a much clearer separation of concerns in the first example.

My goal is to keep our voting artefacts as far away from our release
artefacts as possible.

Re: Tweaking the release procedure

[Adam Kocoloski <ko...@apache.org>]

On Oct 21, 2011, at 3:57 PM, Noah Slater wrote:

> On Fri, Oct 21, 2011 at 8:54 PM, Adam Kocoloski <ko...@apache.org> wrote:
> 
> 
>> Good suggestion on the -vote1 suffix instead of -rc1.  Gets my vote.  Best,
>> 
> 
> It sounds trivial, but I think it's important to namespace these instead of
> using suffixes.

Sure, that works.  It makes little difference to me.  Why do you think it's important?

Re: Tweaking the release procedure

[Noah Slater <ns...@tumbolia.org>]

On Fri, Oct 21, 2011 at 8:54 PM, Adam Kocoloski <ko...@apache.org> wrote:


> Good suggestion on the -vote1 suffix instead of -rc1.  Gets my vote.  Best,
>

It sounds trivial, but I think it's important to namespace these instead of
using suffixes.

Re: Tweaking the release procedure

[Adam Kocoloski <ko...@apache.org>]

On Oct 21, 2011, at 3:51 PM, Jan Lehnardt wrote:

> 
> On Oct 21, 2011, at 21:26 , Adam Kocoloski wrote:
> 
>> Hmmm ... that's all well and good, but I envision more confusion ensuing in the case where we have multiple possible values for '1.1.1' floating around the internet than I do in the case where we have '1.1.1-rc1', '1.1.1-rc2', and eventually one single immutable '1.1.1'.  Best,
> 
> I really like the idea of immutable tags, now that we can have them and the final move from x.y.z-rcX to x.y.z for the passed release including keeping tags for votes that were turned down.
> 
> I'm also totally happy to call it x.y.z-vote1, -vote2 etc. to avoid confusion with RC releases that are releases as defined by the Apache release procedure that I know other projects do.
> 
> Cheers
> Jan

Good suggestion on the -vote1 suffix instead of -rc1.  Gets my vote.  Best,

Adam

Re: Tweaking the release procedure

[Jan Lehnardt <ja...@apache.org>]

On Oct 21, 2011, at 21:26 , Adam Kocoloski wrote:

> Hmmm ... that's all well and good, but I envision more confusion ensuing in the case where we have multiple possible values for '1.1.1' floating around the internet than I do in the case where we have '1.1.1-rc1', '1.1.1-rc2', and eventually one single immutable '1.1.1'.  Best,

I really like the idea of immutable tags, now that we can have them and the final move from x.y.z-rcX to x.y.z for the passed release including keeping tags for votes that were turned down.

I'm also totally happy to call it x.y.z-vote1, -vote2 etc. to avoid confusion with RC releases that are releases as defined by the Apache release procedure that I know other projects do.

Cheers
Jan
-- 




> 
> Adam
> 
> On Oct 21, 2011, at 2:29 PM, Robert Newson wrote:
> 
>> From the other thread, reposted here on Noah's suggestion;
>> 
>> My take on tagging was to follow what we did with SVN with only minor
>> changes to account for git. So I shall describe it.
>> 
>> First, I create a signed tag for the release, with its intended final
>> release value. In this case, exactly the string '1.1.1'. Then I build
>> artifacts from the tag (which could be from a 'git archive 1.1.1' or
>> 'git checkout 1.1.1 && git clean -xdfq'). When I'm happy with the
>> output of that phase (i.e, I've done the diff -r, make check, Futon,
>> etc from the generated tar.gz) I upload it to people.apache.org and
>> push the tag (so that others can verify that it matches the release
>> artifact).
>> 
>> In the event of a round veto, I delete the 1.1.1 tag. In the next
>> round, I create and push a new signed 1.1.1 tag as part of the same
>> procedure.
>> 
>> 'git pull --tags' correctly updates anyone's existing (but now wrong)
>> 1.1.1 tag (the man page for git-tag goes on at some length that it
>> doesn't do that and how evil such a thing would be, but it does it
>> anyway).
>> 
>> The arguments in the other thread about immutable tags are laudable
>> but irrelevant. The tags in our source control system are not the
>> source of truth for our releases. The presence of the release on the
>> Apache mirrors is. The entire discussion around -rcX suffixes is to
>> avoid any confusion between the failed artifacts and the release
>> artifact. While a genuine concern, it's not worth all this soul
>> searching in my opinion. The real 1.1.1 comes from the mirrors. When
>> it's available on our mirrors then it also means that the 1.1.1 tag in
>> source control points to it (and always will).
>> 
>> B.
>> 
>> On 21 October 2011 19:25, Robert Newson <ro...@gmail.com> wrote:
>>> Dustin,
>>> 
>>> 
>>> /tmp/bar $ git --version
>>> git version 1.7.6.1
>>> 
>>> /tmp/bar $ git pull --tags
>>> remote: Counting objects: 4, done.
>>> remote: Compressing objects: 100% (2/2), done.
>>> remote: Total 3 (delta 0), reused 0 (delta 0)
>>> Unpacking objects: 100% (3/3), done.
>>> From /tmp/foo
>>> - [tag update]      1.0        -> 1.0
>>> Fetching tags only, you probably meant:
>>> git fetch --tags
>>> 
>>> The 1.0 tag was correctly updated.
>>> 
>>> B.
>>> 
>>> On 21 October 2011 19:11, Noah Slater <ns...@tumbolia.org> wrote:
>>>> On Fri, Oct 21, 2011 at 7:04 PM, Dustin Sallings <du...@spy.net> wrote:
>>>> 
>>>> IMO, simplicity and conventions win here.  Tags should be treated as
>>>>> immutable pointers to commits that had some meaning and should be named and
>>>>> labeled meaningfully as well.  Branches are pointers to works in progress.
>>>>> When work is "finished", they can be tagged and deleted.  If you do this,
>>>>> all of the defaults work and you don't have to invent and document as much.
>>>>> 
>>>> 
>>>> The only way I can see this working then is to "move" the tag once a vote
>>>> passes. Whether this involves duplicating the tag, or creating a new one
>>>> that points to the same thing, I don't know. Other people with more Git-fu
>>>> can step in here. But we need a way of blessing tags that works with
>>>> downstream repositories, and that separates them out from defunct tags that
>>>> never made the cut.
>>>> 
>>> 
> 

Re: Tweaking the release procedure

[Adam Kocoloski <ko...@apache.org>]

Hmmm ... that's all well and good, but I envision more confusion ensuing in the case where we have multiple possible values for '1.1.1' floating around the internet than I do in the case where we have '1.1.1-rc1', '1.1.1-rc2', and eventually one single immutable '1.1.1'.  Best,

Adam

On Oct 21, 2011, at 2:29 PM, Robert Newson wrote:

> From the other thread, reposted here on Noah's suggestion;
> 
> My take on tagging was to follow what we did with SVN with only minor
> changes to account for git. So I shall describe it.
> 
> First, I create a signed tag for the release, with its intended final
> release value. In this case, exactly the string '1.1.1'. Then I build
> artifacts from the tag (which could be from a 'git archive 1.1.1' or
> 'git checkout 1.1.1 && git clean -xdfq'). When I'm happy with the
> output of that phase (i.e, I've done the diff -r, make check, Futon,
> etc from the generated tar.gz) I upload it to people.apache.org and
> push the tag (so that others can verify that it matches the release
> artifact).
> 
> In the event of a round veto, I delete the 1.1.1 tag. In the next
> round, I create and push a new signed 1.1.1 tag as part of the same
> procedure.
> 
> 'git pull --tags' correctly updates anyone's existing (but now wrong)
> 1.1.1 tag (the man page for git-tag goes on at some length that it
> doesn't do that and how evil such a thing would be, but it does it
> anyway).
> 
> The arguments in the other thread about immutable tags are laudable
> but irrelevant. The tags in our source control system are not the
> source of truth for our releases. The presence of the release on the
> Apache mirrors is. The entire discussion around -rcX suffixes is to
> avoid any confusion between the failed artifacts and the release
> artifact. While a genuine concern, it's not worth all this soul
> searching in my opinion. The real 1.1.1 comes from the mirrors. When
> it's available on our mirrors then it also means that the 1.1.1 tag in
> source control points to it (and always will).
> 
> B.
> 
> On 21 October 2011 19:25, Robert Newson <ro...@gmail.com> wrote:
>> Dustin,
>> 
>> 
>> /tmp/bar $ git --version
>> git version 1.7.6.1
>> 
>> /tmp/bar $ git pull --tags
>> remote: Counting objects: 4, done.
>> remote: Compressing objects: 100% (2/2), done.
>> remote: Total 3 (delta 0), reused 0 (delta 0)
>> Unpacking objects: 100% (3/3), done.
>> From /tmp/foo
>>  - [tag update]      1.0        -> 1.0
>> Fetching tags only, you probably meant:
>>  git fetch --tags
>> 
>> The 1.0 tag was correctly updated.
>> 
>> B.
>> 
>> On 21 October 2011 19:11, Noah Slater <ns...@tumbolia.org> wrote:
>>> On Fri, Oct 21, 2011 at 7:04 PM, Dustin Sallings <du...@spy.net> wrote:
>>> 
>>> IMO, simplicity and conventions win here.  Tags should be treated as
>>>> immutable pointers to commits that had some meaning and should be named and
>>>> labeled meaningfully as well.  Branches are pointers to works in progress.
>>>>  When work is "finished", they can be tagged and deleted.  If you do this,
>>>> all of the defaults work and you don't have to invent and document as much.
>>>> 
>>> 
>>> The only way I can see this working then is to "move" the tag once a vote
>>> passes. Whether this involves duplicating the tag, or creating a new one
>>> that points to the same thing, I don't know. Other people with more Git-fu
>>> can step in here. But we need a way of blessing tags that works with
>>> downstream repositories, and that separates them out from defunct tags that
>>> never made the cut.
>>> 
>> 

Re: Tweaking the release procedure

[Noah Slater <ns...@tumbolia.org>]

On Fri, Oct 21, 2011 at 7:29 PM, Robert Newson <rn...@apache.org> wrote:

The arguments in the other thread about immutable tags are laudable
> but irrelevant. The tags in our source control system are not the
> source of truth for our releases. The presence of the release on the
> Apache mirrors is. The entire discussion around -rcX suffixes is to
> avoid any confusion between the failed artifacts and the release
> artifact. While a genuine concern, it's not worth all this soul
> searching in my opinion. The real 1.1.1 comes from the mirrors. When
> it's available on our mirrors then it also means that the 1.1.1 tag in
> source control points to it (and always will).
>

I don't think this is true.

It's important to have a concrete pointer to the source that produced the
official release artefacts. I don't think it's good enough to just say
"whatever is under dist/ is the release artefact, you can't rely on our Git
to mean anything."

Re: Tweaking the release procedure

[Robert Newson <rn...@apache.org>]

>From the other thread, reposted here on Noah's suggestion;

My take on tagging was to follow what we did with SVN with only minor
changes to account for git. So I shall describe it.

First, I create a signed tag for the release, with its intended final
release value. In this case, exactly the string '1.1.1'. Then I build
artifacts from the tag (which could be from a 'git archive 1.1.1' or
'git checkout 1.1.1 && git clean -xdfq'). When I'm happy with the
output of that phase (i.e, I've done the diff -r, make check, Futon,
etc from the generated tar.gz) I upload it to people.apache.org and
push the tag (so that others can verify that it matches the release
artifact).

In the event of a round veto, I delete the 1.1.1 tag. In the next
round, I create and push a new signed 1.1.1 tag as part of the same
procedure.

'git pull --tags' correctly updates anyone's existing (but now wrong)
1.1.1 tag (the man page for git-tag goes on at some length that it
doesn't do that and how evil such a thing would be, but it does it
anyway).

The arguments in the other thread about immutable tags are laudable
but irrelevant. The tags in our source control system are not the
source of truth for our releases. The presence of the release on the
Apache mirrors is. The entire discussion around -rcX suffixes is to
avoid any confusion between the failed artifacts and the release
artifact. While a genuine concern, it's not worth all this soul
searching in my opinion. The real 1.1.1 comes from the mirrors. When
it's available on our mirrors then it also means that the 1.1.1 tag in
source control points to it (and always will).

B.

On 21 October 2011 19:25, Robert Newson <ro...@gmail.com> wrote:
> Dustin,
>
>
> /tmp/bar $ git --version
> git version 1.7.6.1
>
> /tmp/bar $ git pull --tags
> remote: Counting objects: 4, done.
> remote: Compressing objects: 100% (2/2), done.
> remote: Total 3 (delta 0), reused 0 (delta 0)
> Unpacking objects: 100% (3/3), done.
> From /tmp/foo
>  - [tag update]      1.0        -> 1.0
> Fetching tags only, you probably meant:
>  git fetch --tags
>
> The 1.0 tag was correctly updated.
>
> B.
>
> On 21 October 2011 19:11, Noah Slater <ns...@tumbolia.org> wrote:
>> On Fri, Oct 21, 2011 at 7:04 PM, Dustin Sallings <du...@spy.net> wrote:
>>
>> IMO, simplicity and conventions win here.  Tags should be treated as
>>> immutable pointers to commits that had some meaning and should be named and
>>> labeled meaningfully as well.  Branches are pointers to works in progress.
>>>  When work is "finished", they can be tagged and deleted.  If you do this,
>>> all of the defaults work and you don't have to invent and document as much.
>>>
>>
>> The only way I can see this working then is to "move" the tag once a vote
>> passes. Whether this involves duplicating the tag, or creating a new one
>> that points to the same thing, I don't know. Other people with more Git-fu
>> can step in here. But we need a way of blessing tags that works with
>> downstream repositories, and that separates them out from defunct tags that
>> never made the cut.
>>
>

Re: Tweaking the release procedure

[Paul Davis <pa...@gmail.com>]

On Fri, Oct 21, 2011 at 2:42 PM, Dustin Sallings <du...@spy.net> wrote:
>
> On Oct 21, 2011, at 11:25 AM, Robert Newson wrote:
>
>> /tmp/bar $ git pull --tags
>> remote: Counting objects: 4, done.
>> remote: Compressing objects: 100% (2/2), done.
>> remote: Total 3 (delta 0), reused 0 (delta 0)
>> Unpacking objects: 100% (3/3), done.
>> From /tmp/foo
>> - [tag update]      1.0        -> 1.0
>> Fetching tags only, you probably meant:
>>  git fetch --tags
>>
>> The 1.0 tag was correctly updated.
>
>
>        You aren't disagreeing with the thing I'm most concerned, but the thing I'm second-to-most concerned about but directly brought up.
>
>        I pointed out that you can't *remove* tags, since that's what's required for a renaming strategy.  Here you're just showing that if every user everywhere who has a clone of the official repo issues a non-default update command before looking at tags, then there's no problem.  I think this might be less reasonable than it sounds.

I think our wires were crossed a bit. The rename isn't really a rename
directly. Once a release is made, we just copy the final vote tag to a
new tag that is prefixed/suffixed/something to indicate "this is the
tag that corresponds to what's in the dist directory."

Removing tags would occur after a final vote passed and would only be
a minor "maybe get rid of cruft to avoid confusion" step.

>
>        For example:  Let's say I'm doing an automated build for my OS distribution from the 1.0 tag and have shipped stuff out to my customers.  How will you know that there was no failure in my two tiers of git repos that caused my build to miss the update to your 1.0 tag between the time that you issued the first one, announced the second one, I did an update from a mirror during an upstream outage and see the 1.0 tag and ship it and then find a bug?  Which 1.0 did I ship?
>

Right, this is the current state of affairs we've been dealing with
using SVN and what we're looking to fix.

> --
> dustin sallings
>
>
>
>

Re: Tweaking the release procedure

[Jason Smith <jh...@iriscouch.com>]

A VAR or system integrator's perspective:

On Sat, Oct 22, 2011 at 2:54 AM, Noah Slater <ns...@tumbolia.org> wrote:
> ... Okay. Not sure what happened there. So, uh...
>
> Can we do something like this:
>
> It's the first round of voting, so we tag to:
>
>    vote/X.Y.X-1

Please reconsider semantic versioning. When I read its brief spec, I
hear Noah's voice. The writing is brief, thoughtful, and persuasive.

Couch is trailblazing, discovering best practices for all of ASF. Now
is its chance to adopt a worthy standard. Tagging is Git's strong
suit, and Couch can exploit that.

VAR-type tools and products orbiting couch are numerous and multiplying.

1. Refuge, led by Benoit, a committer
2. Iris Couch builds
3. Build CouchDB
4. Couchbase, involving four committers
5. BigCouch, involving three committers
6. Paul's (a committer) standardization project, couchdb-srcmv
7. Randall's (a committer) Ubuntu PPA
8. Novacut's (free software video editor) Ubuntu PPA
9. Dave Cottlehuber's Windows work
10. An OSGi plug-in wrapper around CouchDB, so one can deploy a
CouchDB runtime into an OSGi

These sorts of projects benefit from semver. Couch already follows
semver's numbering scheme (as closely as makes no difference). What
remains is to indicate this fact.

I urge you to weigh the aesthetic cost and risk of confusion against
pretty clear, common, and **machine-readable** version semantics, and
the opportunity cost of passing on that.

>
> This vote fails, so we move on to the second round of voting, and we tag to:
>
>    vote/X-Y.X-2
>
> This vote passes, so we copy the tag to:
>
>    release/X.Y.Z
>
> We then leave both the vote/* tags in place because they're prefixed to
> avoid confusion.

Leaving tags for posterity is prudent. It opens the door for tools to
identify changes, or discover bugs (git bisect), or perform
integration testing at major events in Couch's lifetime. If only there
was a standard means for tools to infer facts about Couch tags.

Noah, I like your idea of persistent, unchanging tags, and "copying"
(tag the same commit twice) the final vote to the official release.
But note that ./bootstrap inspects Git metadata, potentially executing
different code from one tag to the next. Currently this is not the
case, but the Good Intentions Paving Company is open for business.

http://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=blob;f=bootstrap;h=1190280c200b4f234e8af08f23a45e97fa7e6e93;hb=HEAD#l35

-- 
Iris Couch

Re: Tweaking the release procedure

[Noah Slater <ns...@tumbolia.org>]

... Okay. Not sure what happened there. So, uh...

Can we do something like this:

It's the first round of voting, so we tag to:

    vote/X.Y.X-1

This vote fails, so we move on to the second round of voting, and we tag to:

    vote/X-Y.X-2

This vote passes, so we copy the tag to:

    release/X.Y.Z

We then leave both the vote/* tags in place because they're prefixed to
avoid confusion.


On Fri, Oct 21, 2011 at 8:49 PM, Noah Slater <ns...@tumbolia.org> wrote:

> Can we do something like this:
>
>
>
> On Fri, Oct 21, 2011 at 8:42 PM, Dustin Sallings <du...@spy.net> wrote:
>
>>
>> On Oct 21, 2011, at 11:25 AM, Robert Newson wrote:
>>
>> > /tmp/bar $ git pull --tags
>> > remote: Counting objects: 4, done.
>> > remote: Compressing objects: 100% (2/2), done.
>> > remote: Total 3 (delta 0), reused 0 (delta 0)
>> > Unpacking objects: 100% (3/3), done.
>> > From /tmp/foo
>> > - [tag update]      1.0        -> 1.0
>> > Fetching tags only, you probably meant:
>> >  git fetch --tags
>> >
>> > The 1.0 tag was correctly updated.
>>
>>
>>         You aren't disagreeing with the thing I'm most concerned, but the
>> thing I'm second-to-most concerned about but directly brought up.
>>
>>        I pointed out that you can't *remove* tags, since that's what's
>> required for a renaming strategy.  Here you're just showing that if every
>> user everywhere who has a clone of the official repo issues a non-default
>> update command before looking at tags, then there's no problem.  I think
>> this might be less reasonable than it sounds.
>>
>>        For example:  Let's say I'm doing an automated build for my OS
>> distribution from the 1.0 tag and have shipped stuff out to my customers.
>>  How will you know that there was no failure in my two tiers of git repos
>> that caused my build to miss the update to your 1.0 tag between the time
>> that you issued the first one, announced the second one, I did an update
>> from a mirror during an upstream outage and see the 1.0 tag and ship it and
>> then find a bug?  Which 1.0 did I ship?
>>
>> --
>> dustin sallings
>>
>>
>>
>>
>

Re: Tweaking the release procedure

[Noah Slater <ns...@tumbolia.org>]

Can we do something like this:



On Fri, Oct 21, 2011 at 8:42 PM, Dustin Sallings <du...@spy.net> wrote:

>
> On Oct 21, 2011, at 11:25 AM, Robert Newson wrote:
>
> > /tmp/bar $ git pull --tags
> > remote: Counting objects: 4, done.
> > remote: Compressing objects: 100% (2/2), done.
> > remote: Total 3 (delta 0), reused 0 (delta 0)
> > Unpacking objects: 100% (3/3), done.
> > From /tmp/foo
> > - [tag update]      1.0        -> 1.0
> > Fetching tags only, you probably meant:
> >  git fetch --tags
> >
> > The 1.0 tag was correctly updated.
>
>
>         You aren't disagreeing with the thing I'm most concerned, but the
> thing I'm second-to-most concerned about but directly brought up.
>
>        I pointed out that you can't *remove* tags, since that's what's
> required for a renaming strategy.  Here you're just showing that if every
> user everywhere who has a clone of the official repo issues a non-default
> update command before looking at tags, then there's no problem.  I think
> this might be less reasonable than it sounds.
>
>        For example:  Let's say I'm doing an automated build for my OS
> distribution from the 1.0 tag and have shipped stuff out to my customers.
>  How will you know that there was no failure in my two tiers of git repos
> that caused my build to miss the update to your 1.0 tag between the time
> that you issued the first one, announced the second one, I did an update
> from a mirror during an upstream outage and see the 1.0 tag and ship it and
> then find a bug?  Which 1.0 did I ship?
>
> --
> dustin sallings
>
>
>
>

Re: Tweaking the release procedure

[Jan Lehnardt <ja...@apache.org>]

On Oct 21, 2011, at 21:51 , Adam Kocoloski wrote:

> On Oct 21, 2011, at 3:42 PM, Dustin Sallings wrote:
> 
>> 
>> On Oct 21, 2011, at 11:25 AM, Robert Newson wrote:
>> 
>>> /tmp/bar $ git pull --tags
>>> remote: Counting objects: 4, done.
>>> remote: Compressing objects: 100% (2/2), done.
>>> remote: Total 3 (delta 0), reused 0 (delta 0)
>>> Unpacking objects: 100% (3/3), done.
>>> From /tmp/foo
>>> - [tag update]      1.0        -> 1.0
>>> Fetching tags only, you probably meant:
>>> git fetch --tags
>>> 
>>> The 1.0 tag was correctly updated.
>> 
>> 
>> 	You aren't disagreeing with the thing I'm most concerned, but the thing I'm second-to-most concerned about but directly brought up.
>> 
>> 	I pointed out that you can't *remove* tags, since that's what's required for a renaming strategy.  Here you're just showing that if every user everywhere who has a clone of the official repo issues a non-default update command before looking at tags, then there's no problem.  I think this might be less reasonable than it sounds.
>> 
>> 	For example:  Let's say I'm doing an automated build for my OS distribution from the 1.0 tag and have shipped stuff out to my customers.  How will you know that there was no failure in my two tiers of git repos that caused my build to miss the update to your 1.0 tag between the time that you issued the first one, announced the second one, I did an update from a mirror during an upstream outage and see the 1.0 tag and ship it and then find a bug?  Which 1.0 did I ship?
> 
> +1
> 
> We can argue that the only true '1.1.1' is the tarball you grab from the ASF mirrors, but realistically the type of scenario Dustin describes is pretty darn common.

yes, agreed, it will make downstream life a lot easier and it doesn't cost us anything (aside from agreeing on it and writing it down) to follow this procedure.

Cheers
Jan
-- 

Re: Tweaking the release procedure

[Adam Kocoloski <ko...@apache.org>]

On Oct 21, 2011, at 3:42 PM, Dustin Sallings wrote:

> 
> On Oct 21, 2011, at 11:25 AM, Robert Newson wrote:
> 
>> /tmp/bar $ git pull --tags
>> remote: Counting objects: 4, done.
>> remote: Compressing objects: 100% (2/2), done.
>> remote: Total 3 (delta 0), reused 0 (delta 0)
>> Unpacking objects: 100% (3/3), done.
>> From /tmp/foo
>> - [tag update]      1.0        -> 1.0
>> Fetching tags only, you probably meant:
>> git fetch --tags
>> 
>> The 1.0 tag was correctly updated.
> 
> 
> 	You aren't disagreeing with the thing I'm most concerned, but the thing I'm second-to-most concerned about but directly brought up.
> 
> 	I pointed out that you can't *remove* tags, since that's what's required for a renaming strategy.  Here you're just showing that if every user everywhere who has a clone of the official repo issues a non-default update command before looking at tags, then there's no problem.  I think this might be less reasonable than it sounds.
> 
> 	For example:  Let's say I'm doing an automated build for my OS distribution from the 1.0 tag and have shipped stuff out to my customers.  How will you know that there was no failure in my two tiers of git repos that caused my build to miss the update to your 1.0 tag between the time that you issued the first one, announced the second one, I did an update from a mirror during an upstream outage and see the 1.0 tag and ship it and then find a bug?  Which 1.0 did I ship?

+1

We can argue that the only true '1.1.1' is the tarball you grab from the ASF mirrors, but realistically the type of scenario Dustin describes is pretty darn common.

Re: Tweaking the release procedure

[Dustin Sallings <du...@spy.net>]

On Oct 21, 2011, at 11:25 AM, Robert Newson wrote:

> /tmp/bar $ git pull --tags
> remote: Counting objects: 4, done.
> remote: Compressing objects: 100% (2/2), done.
> remote: Total 3 (delta 0), reused 0 (delta 0)
> Unpacking objects: 100% (3/3), done.
> From /tmp/foo
> - [tag update]      1.0        -> 1.0
> Fetching tags only, you probably meant:
>  git fetch --tags
> 
> The 1.0 tag was correctly updated.


	You aren't disagreeing with the thing I'm most concerned, but the thing I'm second-to-most concerned about but directly brought up.

	I pointed out that you can't *remove* tags, since that's what's required for a renaming strategy.  Here you're just showing that if every user everywhere who has a clone of the official repo issues a non-default update command before looking at tags, then there's no problem.  I think this might be less reasonable than it sounds.

	For example:  Let's say I'm doing an automated build for my OS distribution from the 1.0 tag and have shipped stuff out to my customers.  How will you know that there was no failure in my two tiers of git repos that caused my build to miss the update to your 1.0 tag between the time that you issued the first one, announced the second one, I did an update from a mirror during an upstream outage and see the 1.0 tag and ship it and then find a bug?  Which 1.0 did I ship?

-- 
dustin sallings

Re: Tweaking the release procedure

[Robert Newson <ro...@gmail.com>]

Dustin,


/tmp/bar $ git --version
git version 1.7.6.1

/tmp/bar $ git pull --tags
remote: Counting objects: 4, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
>From /tmp/foo
 - [tag update]      1.0        -> 1.0
Fetching tags only, you probably meant:
  git fetch --tags

The 1.0 tag was correctly updated.

B.

On 21 October 2011 19:11, Noah Slater <ns...@tumbolia.org> wrote:
> On Fri, Oct 21, 2011 at 7:04 PM, Dustin Sallings <du...@spy.net> wrote:
>
> IMO, simplicity and conventions win here.  Tags should be treated as
>> immutable pointers to commits that had some meaning and should be named and
>> labeled meaningfully as well.  Branches are pointers to works in progress.
>>  When work is "finished", they can be tagged and deleted.  If you do this,
>> all of the defaults work and you don't have to invent and document as much.
>>
>
> The only way I can see this working then is to "move" the tag once a vote
> passes. Whether this involves duplicating the tag, or creating a new one
> that points to the same thing, I don't know. Other people with more Git-fu
> can step in here. But we need a way of blessing tags that works with
> downstream repositories, and that separates them out from defunct tags that
> never made the cut.
>

Re: Tweaking the release procedure

[Noah Slater <ns...@tumbolia.org>]

On Fri, Oct 21, 2011 at 7:04 PM, Dustin Sallings <du...@spy.net> wrote:

IMO, simplicity and conventions win here.  Tags should be treated as
> immutable pointers to commits that had some meaning and should be named and
> labeled meaningfully as well.  Branches are pointers to works in progress.
>  When work is "finished", they can be tagged and deleted.  If you do this,
> all of the defaults work and you don't have to invent and document as much.
>

The only way I can see this working then is to "move" the tag once a vote
passes. Whether this involves duplicating the tag, or creating a new one
that points to the same thing, I don't know. Other people with more Git-fu
can step in here. But we need a way of blessing tags that works with
downstream repositories, and that separates them out from defunct tags that
never made the cut.

Re: Tweaking the release procedure

[Dustin Sallings <du...@spy.net>]

On Oct 21, 2011, at 9:43 AM, Robert Newson wrote:

> I'll also note that 'git pull --tags' will update any tags that have
> changed, despite what the man page for git-tags actually says.


dustinnmb:/tmp/test 695% mkdir upstream
dustinnmb:/tmp/test 696% cd upstream/
dustinnmb:/tmp/test/upstream 697% git init
Initialized empty Git repository in /private/tmp/test/upstream/.git/
dustinnmb:/tmp/test/upstream 698% git commit --allow-empty -m first
[master (root-commit) ca3e451] first
dustinnmb:/tmp/test/upstream 699% git tag -am 'beginning of time' testing
dustinnmb:/tmp/test/upstream 700% cd ..
dustinnmb:/tmp/test 701% git clone upstream downstream
Cloning into downstream...
done.
dustinnmb:/tmp/test 702% cd upstream/
dustinnmb:/tmp/test/upstream 703% git tag -d testing
Deleted tag 'testing' (was 21f1c92)
dustinnmb:/tmp/test/upstream 704% cd ../downstream/
dustinnmb:/tmp/test/downstream 705% git pull --tags
Fetching tags only, you probably meant:
  git fetch --tags
dustinnmb:/tmp/test/downstream 706% git fetch --tags
dustinnmb:/tmp/test/downstream 707% git tag
testing


	Deleting tags is hard.

	Updating them is slightly less hard, but requires users to be performing non-default behavior, and I think that leads to far, far more confusion as there's no way to know whether the users are doing the non-default things that cause your pointers to propagate, e.g.:  "I'm running 1.1.1". "Which 1.1.1?"

	IMO, simplicity and conventions win here.  Tags should be treated as immutable pointers to commits that had some meaning and should be named and labeled meaningfully as well.  Branches are pointers to works in progress.  When work is "finished", they can be tagged and deleted.  If you do this, all of the defaults work and you don't have to invent and document as much.

	I'm not trying to suggest you guys are doing a bad job or don't know what you're doing, or should be using bcrypt or anything.  I'm just pointing out that some of the suggestions in this thread will lead to technical difficulties.  "temporary tag" isn't meaningful outside of a local repository.  And it's really easy to accidentally push one.  And it's nearly impossible to tell where it goes after you push it (e.g. every one of my github repos automatically triggers replication on every push).


-- 
dustin sallings

Re: Tweaking the release procedure

[Robert Newson <rn...@apache.org>]

I'll also note that 'git pull --tags' will update any tags that have
changed, despite what the man page for git-tags actually says.

B.

On 21 October 2011 17:39, Robert Dionne <di...@dionne-associates.com> wrote:
>
>
> On Oct 21, 2011, at 12:33 PM, Paul Davis wrote:
>
>> On Fri, Oct 21, 2011 at 4:28 AM, Jukka Zitting <ju...@gmail.com> wrote:
>>> Hi,
>>>
>>> My 2c from the gallery. I'm not involved in CouchDB, so just making
>>> general observations from the perspective of other Apache projects
>>> interested in using Git.
>>>
>>> On Fri, Oct 21, 2011 at 5:51 AM, Paul Davis <pa...@gmail.com> wrote:
>>>> As Noah points out, there are ASF procedural issues that affect this
>>>> discussion. Part of making a release involves getting community input
>>>> on whether the release is a valid artefact. As such we need to be able
>>>> to refer to these "not-release" sets of bytes.
>>>
>>> I'd say that's a perfectly valid use of tags. An official release
>>> should be backed by a tag, but there's no requirement for the reverse.
>>> Using tags for release candidates or other milestones should also be
>>> fine. It should be up to each project to decide how they want to name
>>> and manage tags.
>>>
>>> I also find the idea of renaming a release tag after the vote
>>> completes a bit troublesome. The way I see it, a release manager will
>>> tag a given state of the source tree and use that tag to build the
>>> release candidate. After that no repository changes should be required
>>> regardless of the result of the release vote. If the vote passes, the
>>> candidate packages are pushed to www.apache.org/dist as-is. Otherwise
>>> the release candidate is just dropped and the next one made.
>>>
>>> This kind of a workflow also solves the "1.1.1 vs. 1.1.1-rc1" problem.
>>> If each release candidate is given a separate new tag and version
>>> number (i.e. "1.1.1 vs 1.1.2"), then there can be no confusion about
>>> which build is being tested. Version numbers are cheap.
>>>
>>> BR,
>>>
>>> Jukka Zitting
>>>
>>
>> Are there projects that do this version incrementing when a vote
>> fails? That's an idea I haven't heard before.
>
> I think this is pretty common
>
>
>
>

Re: Tweaking the release procedure

[Robert Dionne <di...@dionne-associates.com>]

On Oct 21, 2011, at 12:33 PM, Paul Davis wrote:

> On Fri, Oct 21, 2011 at 4:28 AM, Jukka Zitting <ju...@gmail.com> wrote:
>> Hi,
>> 
>> My 2c from the gallery. I'm not involved in CouchDB, so just making
>> general observations from the perspective of other Apache projects
>> interested in using Git.
>> 
>> On Fri, Oct 21, 2011 at 5:51 AM, Paul Davis <pa...@gmail.com> wrote:
>>> As Noah points out, there are ASF procedural issues that affect this
>>> discussion. Part of making a release involves getting community input
>>> on whether the release is a valid artefact. As such we need to be able
>>> to refer to these "not-release" sets of bytes.
>> 
>> I'd say that's a perfectly valid use of tags. An official release
>> should be backed by a tag, but there's no requirement for the reverse.
>> Using tags for release candidates or other milestones should also be
>> fine. It should be up to each project to decide how they want to name
>> and manage tags.
>> 
>> I also find the idea of renaming a release tag after the vote
>> completes a bit troublesome. The way I see it, a release manager will
>> tag a given state of the source tree and use that tag to build the
>> release candidate. After that no repository changes should be required
>> regardless of the result of the release vote. If the vote passes, the
>> candidate packages are pushed to www.apache.org/dist as-is. Otherwise
>> the release candidate is just dropped and the next one made.
>> 
>> This kind of a workflow also solves the "1.1.1 vs. 1.1.1-rc1" problem.
>> If each release candidate is given a separate new tag and version
>> number (i.e. "1.1.1 vs 1.1.2"), then there can be no confusion about
>> which build is being tested. Version numbers are cheap.
>> 
>> BR,
>> 
>> Jukka Zitting
>> 
> 
> Are there projects that do this version incrementing when a vote
> fails? That's an idea I haven't heard before.

I think this is pretty common

Re: Tweaking the release procedure

[Noah Slater <ns...@tumbolia.org>]

FWIW, I don't think this isn't going to work for us.

I will post a full explanation later today when I have some free time.

On Fri, Oct 21, 2011 at 5:33 PM, Paul Davis <pa...@gmail.com>wrote:

> On Fri, Oct 21, 2011 at 4:28 AM, Jukka Zitting <ju...@gmail.com>
> wrote:
> > Hi,
> >
> > My 2c from the gallery. I'm not involved in CouchDB, so just making
> > general observations from the perspective of other Apache projects
> > interested in using Git.
> >
> > On Fri, Oct 21, 2011 at 5:51 AM, Paul Davis <pa...@gmail.com>
> wrote:
> >> As Noah points out, there are ASF procedural issues that affect this
> >> discussion. Part of making a release involves getting community input
> >> on whether the release is a valid artefact. As such we need to be able
> >> to refer to these "not-release" sets of bytes.
> >
> > I'd say that's a perfectly valid use of tags. An official release
> > should be backed by a tag, but there's no requirement for the reverse.
> > Using tags for release candidates or other milestones should also be
> > fine. It should be up to each project to decide how they want to name
> > and manage tags.
> >
> > I also find the idea of renaming a release tag after the vote
> > completes a bit troublesome. The way I see it, a release manager will
> > tag a given state of the source tree and use that tag to build the
> > release candidate. After that no repository changes should be required
> > regardless of the result of the release vote. If the vote passes, the
> > candidate packages are pushed to www.apache.org/dist as-is. Otherwise
> > the release candidate is just dropped and the next one made.
> >
> > This kind of a workflow also solves the "1.1.1 vs. 1.1.1-rc1" problem.
> > If each release candidate is given a separate new tag and version
> > number (i.e. "1.1.1 vs 1.1.2"), then there can be no confusion about
> > which build is being tested. Version numbers are cheap.
> >
> > BR,
> >
> > Jukka Zitting
> >
>
> Are there projects that do this version incrementing when a vote
> fails? That's an idea I haven't heard before.
>

Re: Tweaking the release procedure

[Dustin Sallings <du...@spy.net>]

On Oct 21, 2011, at 2:23 PM, Robert Newson wrote:

> In all vote emails, we include the commit id that the release
> artifacts were built from, but create no tag at all.
> 
> When the release passes the votes, we create the tag, with its final
> name, against that commit id, and push it at the same time we upload
> the artifact to the mirrors.
> 
> To obviate any concern about stale 1.1.1 tags in downstream repos, we
> could, for this release only, add a 1.1.1-final tag as an unambiguous
> tag, but only *after* the release is official.
> 
> Stated another way; we make each tag exactly once, and refer to the
> build by its commit id until then. Since a commit id in git dictates
> the precise state of the entire tree this is safe.


	Makes sense to me.  "git describe" instead of plain commit IDs is pretty good for this as well since they'll be slightly easier to talk about, but same effect.

-- 
dustin sallings

Re: Tweaking the release procedure

[Randall Leeds <ra...@gmail.com>]

On Fri, Oct 21, 2011 at 21:38, Jason Smith <jh...@iriscouch.com> wrote:

> On Sat, Oct 22, 2011 at 10:56 AM, Noah Slater <ns...@tumbolia.org>
> wrote:
> > I am torn now.
> >
> > If being able to tell from Git at what point a release branch was cut for
> a
> > vote (even if that vote failed) is important then I suggest we go with my
> > "vote/" and "release/" prefix idea, and that a release branch is tagged
> once
> > for the vote, and then a second time when it passes. Does anyone need to
> do
> > this? Is it important for anything? Is it worth the complexity and mess
> it
> > will cause for our tag namespace?
>
> It's important to consider polluting or flooding the tag namespace,
> and also the risk of misleading tags which cause people to run
> unofficial releases.
>
> Git originally (and AFAIK primarily) serves the Linux kernel project.
> If other projects find it useful, cool.
>
> Subversion tags are an afterthought; Git tags are a big deal, perhaps
> its best feature. Compared to branches, tags are similar enough to
> make sense; but dissimilar enough to be useful, particularly for
> cutting releases. To risk of repeating what you already know, tags
>
> * Can be cryptographically signed
> * Can carry their own "commit message" (annotation), such as a
> changelog, or release announcement
> * Live in their own clean namespace
>
> The ASF oughtn't repeat old Subversion procedures, but rather adopt
> broader, more modern, more productive Git procedures. For example,
> consider a hypothetical policy:
>
> 1. Tags for a vote must contain as their message body the email
> message calling for that vote
> 2. Tags for releases must contain as their message body the email body
> announcing vote approval
> 3. Tags must be GPG signed by the release manager
>
> What a terrible idea! It duplicates the same data into two places--it
> denormalizes! People might find crucial information from whichever
> data source is more appropriate. Such filth is no doubt unwelcome to
> CouchDB.
>

+<3

Re: Tweaking the release procedure

[Jason Smith <jh...@iriscouch.com>]

On Sat, Oct 22, 2011 at 10:56 AM, Noah Slater <ns...@tumbolia.org> wrote:
> I am torn now.
>
> If being able to tell from Git at what point a release branch was cut for a
> vote (even if that vote failed) is important then I suggest we go with my
> "vote/" and "release/" prefix idea, and that a release branch is tagged once
> for the vote, and then a second time when it passes. Does anyone need to do
> this? Is it important for anything? Is it worth the complexity and mess it
> will cause for our tag namespace?

It's important to consider polluting or flooding the tag namespace,
and also the risk of misleading tags which cause people to run
unofficial releases.

Git originally (and AFAIK primarily) serves the Linux kernel project.
If other projects find it useful, cool.

Subversion tags are an afterthought; Git tags are a big deal, perhaps
its best feature. Compared to branches, tags are similar enough to
make sense; but dissimilar enough to be useful, particularly for
cutting releases. To risk of repeating what you already know, tags

* Can be cryptographically signed
* Can carry their own "commit message" (annotation), such as a
changelog, or release announcement
* Live in their own clean namespace

The ASF oughtn't repeat old Subversion procedures, but rather adopt
broader, more modern, more productive Git procedures. For example,
consider a hypothetical policy:

1. Tags for a vote must contain as their message body the email
message calling for that vote
2. Tags for releases must contain as their message body the email body
announcing vote approval
3. Tags must be GPG signed by the release manager

What a terrible idea! It duplicates the same data into two places--it
denormalizes! People might find crucial information from whichever
data source is more appropriate. Such filth is no doubt unwelcome to
CouchDB.

-- 
Iris Couch

Re: Tweaking the release procedure

[Noah Slater <ns...@tumbolia.org>]

I am torn now.

If being able to tell from Git at what point a release branch was cut for a
vote (even if that vote failed) is important then I suggest we go with my
"vote/" and "release/" prefix idea, and that a release branch is tagged once
for the vote, and then a second time when it passes. Does anyone need to do
this? Is it important for anything? Is it worth the complexity and mess it
will cause for our tag namespace?

If this is not important, then I suggest we post commit hashes (or whatever
else is convenient for enabling people to duplicate the artefact, which is,
of course, the primary reason we do this) of the release branch at the point
it was cut for a vote to the mailing list. Once a vote passes, we tag this
commit without any prefix whatsoever. At the moment, I think I prefer this
option.

In both instances, I think we need to put together a short rationale (I
would do it, but my lack of Git knowledge would hamper my efforts to explain
it properly) and present it to the board for them to bless the idea. In
both scenarios above, we diverge from the Subversion procedure in a fairly
important way. As Jukka has mentioned, the source is traditionally not
modified following a successful vote.

Re: Tweaking the release procedure

[Noah Slater <ns...@tumbolia.org>]

On Sat, Oct 22, 2011 at 4:31 AM, Jason Smith <jh...@iriscouch.com> wrote:


> That sounds like a tag by another name. I hope that official ASF
> releases could have corresponding persistent, unchanging Git tags; and
> also that moments of significance (release votes) would be reflected
> in the repository, rather than the mailing list archives.


Note that it effectively mirrors what we did with Subversion. Every time we
cut a new tag for the vote, we'd delete and recreate the tags/X.Y.Z
directory. So the only way to find what we were voting for, without using
the mailing list, was to look back through the history of that path.
Admittedly, we'd loose the ability to automatically detect when a release
branch was "cut" for the release by looking at Git. But the mailing list
 has that information. So is it really a big deal? The mailing list is a
permanent feature of the project, and just as essential as Git.

Re: Tweaking the release procedure

[Randall Leeds <ra...@gmail.com>]

On Fri, Oct 21, 2011 at 21:34, Randall Leeds <ra...@gmail.com>wrote:

> On Fri, Oct 21, 2011 at 20:31, Jason Smith <jh...@iriscouch.com> wrote:
>
>> On Sat, Oct 22, 2011 at 5:06 AM, Noah Slater <ns...@tumbolia.org>
>> wrote:
>> > On Fri, Oct 21, 2011 at 10:23 PM, Robert Newson <rn...@apache.org>
>> wrote:
>> >
>> >> Here's another suggestion.
>> >>
>> >> In all vote emails, we include the commit id that the release
>> >> artifacts were built from, but create no tag at all.
>> >
>> > I love it when something is so obvious you wonder why it wasn't apparent
>> in
>> > the first place. I love this suggestion, and the specifics of how you
>> > communicate the git commit hash is unimportant. If there's a "describe"
>> > command to make it easier, so be it. We only tag when we mean to tag a
>> > release, for reals.
>>
>> Noah, your previous opinion was superior.
>>
>> Bob, please consider whether you beat yourself up due to old
>> Subversion habits. You shout into the aether, "We are all voting on
>> commit abcdef!" and everybody tries out that commit, understanding
>> that it could be a Big Deal.
>>
>> That sounds like a tag by another name. I hope that official ASF
>> releases could have corresponding persistent, unchanging Git tags; and
>> also that moments of significance (release votes) would be reflected
>> in the repository, rather than the mailing list archives.
>>
>> --
>> Iris Couch
>>
>
> I'll stay brief, because I'm intimidated by this thread.
>
> I hear the call for semver and fully support it. I would be sad if we ended
> up with release/X.Y.Z instead of vX.Y.Z.
>
> Reading over the spec, I see that it calls for ASCII sorting of components,
> which suggests that rc would obsolete vote which means all of the following
> tags are valid and ordered correctly:
>

Whoops! I meant vote would obsolete rc and i've inserted a vote on v1.2 here
to show what I meant to say:


>
> v1.2rc1-vote1
> v1.2rc1-vote2
> v1.2rc1
> v1.2rc2-vote1
> v1.2rc2
>
 v1.2vote1
v1.2vote2

> v1.2
>
> Seems right and simple to me. I'd have to scrutinize it closely and try a
> few, but I'm pretty sure the rpm version comparison would agree with this
> ordering. Anyone know about deb? Others?
>
> If the last vote tag is identical to the release tag in terms of referenced
> commit then that seems to fit all the desired properties of immutability and
> history.
>
> -Randall
>
>

Re: Tweaking the release procedure

[Randall Leeds <ra...@gmail.com>]

On Fri, Oct 21, 2011 at 20:31, Jason Smith <jh...@iriscouch.com> wrote:

> On Sat, Oct 22, 2011 at 5:06 AM, Noah Slater <ns...@tumbolia.org> wrote:
> > On Fri, Oct 21, 2011 at 10:23 PM, Robert Newson <rn...@apache.org>
> wrote:
> >
> >> Here's another suggestion.
> >>
> >> In all vote emails, we include the commit id that the release
> >> artifacts were built from, but create no tag at all.
> >
> > I love it when something is so obvious you wonder why it wasn't apparent
> in
> > the first place. I love this suggestion, and the specifics of how you
> > communicate the git commit hash is unimportant. If there's a "describe"
> > command to make it easier, so be it. We only tag when we mean to tag a
> > release, for reals.
>
> Noah, your previous opinion was superior.
>
> Bob, please consider whether you beat yourself up due to old
> Subversion habits. You shout into the aether, "We are all voting on
> commit abcdef!" and everybody tries out that commit, understanding
> that it could be a Big Deal.
>
> That sounds like a tag by another name. I hope that official ASF
> releases could have corresponding persistent, unchanging Git tags; and
> also that moments of significance (release votes) would be reflected
> in the repository, rather than the mailing list archives.
>
> --
> Iris Couch
>

I'll stay brief, because I'm intimidated by this thread.

I hear the call for semver and fully support it. I would be sad if we ended
up with release/X.Y.Z instead of vX.Y.Z.

Reading over the spec, I see that it calls for ASCII sorting of components,
which suggests that rc would obsolete vote which means all of the following
tags are valid and ordered correctly:

v1.2rc1-vote1
v1.2rc1-vote2
v1.2rc1
v1.2rc2-vote1
v1.2rc2
v1.2

Seems right and simple to me. I'd have to scrutinize it closely and try a
few, but I'm pretty sure the rpm version comparison would agree with this
ordering. Anyone know about deb? Others?

If the last vote tag is identical to the release tag in terms of referenced
commit then that seems to fit all the desired properties of immutability and
history.

-Randall

Re: Tweaking the release procedure

[Jason Smith <jh...@iriscouch.com>]

On Sat, Oct 22, 2011 at 5:06 AM, Noah Slater <ns...@tumbolia.org> wrote:
> On Fri, Oct 21, 2011 at 10:23 PM, Robert Newson <rn...@apache.org> wrote:
>
>> Here's another suggestion.
>>
>> In all vote emails, we include the commit id that the release
>> artifacts were built from, but create no tag at all.
>
> I love it when something is so obvious you wonder why it wasn't apparent in
> the first place. I love this suggestion, and the specifics of how you
> communicate the git commit hash is unimportant. If there's a "describe"
> command to make it easier, so be it. We only tag when we mean to tag a
> release, for reals.

Noah, your previous opinion was superior.

Bob, please consider whether you beat yourself up due to old
Subversion habits. You shout into the aether, "We are all voting on
commit abcdef!" and everybody tries out that commit, understanding
that it could be a Big Deal.

That sounds like a tag by another name. I hope that official ASF
releases could have corresponding persistent, unchanging Git tags; and
also that moments of significance (release votes) would be reflected
in the repository, rather than the mailing list archives.

-- 
Iris Couch

Re: Tweaking the release procedure

[Robert Newson <rn...@apache.org>]

The command should work, it seems like a server-side bug. As I said, I
deleted the round 1 1.1.1 tag and made a new one for round 2, so it's
worked before (and quite recently).

Is it just me?

B.

On 21 October 2011 23:19, Noah Slater <ns...@tumbolia.org> wrote:
> On Fri, Oct 21, 2011 at 11:14 PM, Robert Newson <rn...@apache.org> wrote:
>
>> The only annoying factor is that I can no longer delete the 1.1.1 tag
>>
>
> This seems odd.
>
> I thought there was always a way to undo things in Git?
>
>
>> So, unless someone else can delete it, it will hang around until I
>> change it to its final value. I *won't* be changing it  for round 3 or
>> higher, though, as per the above proposal.
>>
>
> Makes sense.
>
>
>> I'd like a few more +1's for the 'use commit id until official
>> release' policy but there's time, since we're waiting on a Windows fix
>> for the basename() issue.
>>
>
> Agreed.
>
> Perhaps we should involve someone from the board on this?
>
> Seems like an important enough decision.
>

Re: Tweaking the release procedure

[Noah Slater <ns...@tumbolia.org>]

On Fri, Oct 21, 2011 at 11:14 PM, Robert Newson <rn...@apache.org> wrote:

> The only annoying factor is that I can no longer delete the 1.1.1 tag
>

This seems odd.

I thought there was always a way to undo things in Git?


> So, unless someone else can delete it, it will hang around until I
> change it to its final value. I *won't* be changing it  for round 3 or
> higher, though, as per the above proposal.
>

Makes sense.


> I'd like a few more +1's for the 'use commit id until official
> release' policy but there's time, since we're waiting on a Windows fix
> for the basename() issue.
>

Agreed.

Perhaps we should involve someone from the board on this?

Seems like an important enough decision.

Re: Tweaking the release procedure

[Robert Newson <rn...@apache.org>]

The only annoying factor is that I can no longer delete the 1.1.1 tag
(I have deleted it before);

~/source/couchdb $ git push origin :refs/tags/1.1.1
remote: env: python: No such file or directory

So, unless someone else can delete it, it will hang around until I
change it to its final value. I *won't* be changing it  for round 3 or
higher, though, as per the above proposal.

I'd like a few more +1's for the 'use commit id until official
release' policy but there's time, since we're waiting on a Windows fix
for the basename() issue.

To clarify how the vote emails would look, the previous email said;

These artifacts have been built from the 1.1.1 tag in Git:

and, under the new policy, would have said;

These artifacts have been built from commit
89f7faa6d09248999fb51ffd2a13777168f51805

B.

On 21 October 2011 23:06, Noah Slater <ns...@tumbolia.org> wrote:
> On Fri, Oct 21, 2011 at 10:23 PM, Robert Newson <rn...@apache.org> wrote:
>
>> Here's another suggestion.
>>
>> In all vote emails, we include the commit id that the release
>> artifacts were built from, but create no tag at all.
>>
>> When the release passes the votes, we create the tag, with its final
>> name, against that commit id, and push it at the same time we upload
>> the artifact to the mirrors.
>>
>> To obviate any concern about stale 1.1.1 tags in downstream repos, we
>> could, for this release only, add a 1.1.1-final tag as an unambiguous
>> tag, but only *after* the release is official.
>>
>> Stated another way; we make each tag exactly once, and refer to the
>> build by its commit id until then. Since a commit id in git dictates
>> the precise state of the entire tree this is safe.
>
>
> I love it when something is so obvious you wonder why it wasn't apparent in
> the first place. I love this suggestion, and the specifics of how you
> communicate the git commit hash is unimportant. If there's a "describe"
> command to make it easier, so be it. We only tag when we mean to tag a
> release, for reals.
>
> As for the existing Git tags, I don't want to mess things up with a
> 1.1.1-final tag. Let's just accept the fact that some downstream
> repositories may have stale 1.1.1 tags from the previous two rounds, and go
> ahead and delete them. Once the vote passes on 1.1.1, we create a "1.1.1"
> tag as per this suggestion and request that people update their downstream
> git repos to make up for the fact we've now solidified our release procedure
> in a way that means those old tags need to be deleted. Make sense?
>

Re: Tweaking the release procedure

[Adam Kocoloski <ko...@apache.org>]

On Oct 21, 2011, at 8:25 PM, Dustin Sallings wrote:

> 
> On Oct 21, 2011, at 4:52 PM, Adam Kocoloski wrote:
> 
>> `git describe` would read something like 1.1.0-N-deadbeef, where N is the number of commits since the last tag.  On .0 releases it would probably just be the commit hash since the commit would not be a descendant of any tags.  It's a neat tool but I think it might confuse more than illuminate.
> 
> 	It would be terribly unfortunate if there was no trackable lineage between releases.  If version 1.2 does not contain version 1.1, then what does it contain?

Hi Dustin, unfortunate or not that's the way it works.  Think about the procedure we've been discussing in this thread.  All the tags will point to commits on release branches, and those release branches always contain commits which do not live on trunk/master.  Often trivial stuff like setting version numbers in autoconf macros, but sometimes not so trivial stuff, like when we branched 1.2.x so we could get on with the business of landing cool new shit in master while the code slated for the 1.2.0 release undergoes additional testing and stabilization.

Also, I lied.  In the current repo 1.1.1 does not even descend from 1.1.0.  This is because the repo is a former mirror of SVN and in the SVN days each "tag" was actually a new branch unto itself.  The mirror reflects (boo) that fact.

Adam

Re: Tweaking the release procedure

[Robert Newson <rn...@apache.org>]

Yes, I'll document this as I go through round 3, as soon as a fix for
Windows lands.

B.

On 23 October 2011 07:13, Noah Slater <ns...@tumbolia.org> wrote:
> I LOLed.
>
>
> On 23 Oct 2011, at 03:34, Paul Davis <pa...@gmail.com> wrote:
>
>> On Sat, Oct 22, 2011 at 9:10 PM, Noah Slater <ns...@tumbolia.org> wrote:
>>> On Sun, Oct 23, 2011 at 2:50 AM, Paul Davis <pa...@gmail.com>wrote:
>>>
>>> Honestly, I stopped caring about 50 emails ago. Next time I cut a
>>>> release I'll read the CliffsNotes.
>>>
>>>
>>> P.S. If we get to 100 emails in this thread, Sergy Brin will send us all
>>> $100 each.
>>>
>>
>> That'd work out to about $1.79 per hour of my time then. :/
>

Re: Tweaking the release procedure

[Noah Slater <ns...@tumbolia.org>]

I LOLed.


On 23 Oct 2011, at 03:34, Paul Davis <pa...@gmail.com> wrote:

> On Sat, Oct 22, 2011 at 9:10 PM, Noah Slater <ns...@tumbolia.org> wrote:
>> On Sun, Oct 23, 2011 at 2:50 AM, Paul Davis <pa...@gmail.com>wrote:
>>
>> Honestly, I stopped caring about 50 emails ago. Next time I cut a
>>> release I'll read the CliffsNotes.
>>
>>
>> P.S. If we get to 100 emails in this thread, Sergy Brin will send us all
>> $100 each.
>>
>
> That'd work out to about $1.79 per hour of my time then. :/

Re: Tweaking the release procedure

[Paul Davis <pa...@gmail.com>]

On Sat, Oct 22, 2011 at 9:10 PM, Noah Slater <ns...@tumbolia.org> wrote:
> On Sun, Oct 23, 2011 at 2:50 AM, Paul Davis <pa...@gmail.com>wrote:
>
> Honestly, I stopped caring about 50 emails ago. Next time I cut a
>> release I'll read the CliffsNotes.
>
>
> P.S. If we get to 100 emails in this thread, Sergy Brin will send us all
> $100 each.
>

That'd work out to about $1.79 per hour of my time then. :/

Re: Tweaking the release procedure

[Noah Slater <ns...@tumbolia.org>]

On Sun, Oct 23, 2011 at 2:50 AM, Paul Davis <pa...@gmail.com>wrote:

Honestly, I stopped caring about 50 emails ago. Next time I cut a
> release I'll read the CliffsNotes.


P.S. If we get to 100 emails in this thread, Sergy Brin will send us all
$100 each.

Re: Tweaking the release procedure

[Dustin Sallings <du...@spy.net>]

On Oct 22, 2011, at 10:24 PM, Paul Davis wrote:

> For the contents of the tag message itself, I couldn't care less
> really. Anything we add is going to be more helpful than the SVN
> version. Though honestly, when's the last time anyone actually
> *looked* at a tag commit message for useful information. I can tell
> you exactly how many times I have. Zero. If I want to know the change
> log I check it out and and read the file appropriately named CHANGES.

	If nobody cares to put useful information there, then you can't expect it to be very good, could you?

	I have a tiny command that generates this page using only tags and the commits between them:

		http://dustin.github.com/java-memcached-client/changelog.html

-- 
dustin sallings

Re: Tweaking the release procedure

[Paul Davis <pa...@gmail.com>]

On Sat, Oct 22, 2011 at 9:05 PM, Noah Slater <ns...@tumbolia.org> wrote:
> On Sun, Oct 23, 2011 at 2:50 AM, Paul Davis <pa...@gmail.com>wrote:
>
> Honestly, I stopped caring about 50 emails ago. Next time I cut a
>> release I'll read the CliffsNotes.
>
>
> We're close to the end here, Paul. Your (constructive) input would be
> valued. ;)
>

AFAICT there's some discussion about some stuff and some discussion
that's pretty much what I said in the very first email except
s/rel/release/ s/rc/vote/ which is fine. Using vote is better than rc
because its more obvious what's meant.

For the contents of the tag message itself, I couldn't care less
really. Anything we add is going to be more helpful than the SVN
version. Though honestly, when's the last time anyone actually
*looked* at a tag commit message for useful information. I can tell
you exactly how many times I have. Zero. If I want to know the change
log I check it out and and read the file appropriately named CHANGES.

As to massively restructuring our development and maintenance
patterns, I pretty much just ignored all of that. I mean, if we want
to change that, then sure, we can discuss that sort of thing in a
thread that's not about what to name release branches and tags.

So yep.

http://www.youtube.com/watch?v=Otm4RusESNU

Re: Tweaking the release procedure

[Noah Slater <ns...@tumbolia.org>]

On Sun, Oct 23, 2011 at 2:50 AM, Paul Davis <pa...@gmail.com>wrote:

Honestly, I stopped caring about 50 emails ago. Next time I cut a
> release I'll read the CliffsNotes.


We're close to the end here, Paul. Your (constructive) input would be
valued. ;)

Re: Tweaking the release procedure

[Paul Davis <pa...@gmail.com>]

On Sat, Oct 22, 2011 at 1:00 PM, Noah Slater <ns...@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?
>

Honestly, I stopped caring about 50 emails ago. Next time I cut a
release I'll read the CliffsNotes.

> 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 <rn...@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.
>
>
>> 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.
>
>
>> 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.
>
> 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
>

Re: Tweaking the release procedure

[Paul Davis <pa...@gmail.com>]

> 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.

I forgot to point out that we're only expected to be deciding for
CouchDB. Just because we're a test bed for Git doesn't mean that all
other projects have to do things exactly as we have. Pulling version
numbers from Git tags is quite fine if we go that route.

Re: Tweaking the release procedure

[Noah Slater <ns...@tumbolia.org>]

On Sun, Oct 23, 2011 at 6:50 AM, Randall Leeds <ra...@gmail.com>wrote:

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.
>

Strikes me as needless complexity.

Let's leave it with a GPG signature and message pointing to the vote result.

Anything we didn't cover? Is this enough for someone to modify the release
> procedure wiki page to reflect what we will practise?


I think we have a good idea of what we're doing now.

Commit hashes for votes, and signed vanilla tags with link to the vote
results for releases.

Bob, are you able to write this up on the wiki as you go along, copying the
commands needed, etc?

Is this something we want to do for all our previous releases too?

Thanks!

Re: Tweaking the release procedure

[Noah Slater <ns...@tumbolia.org>]

This is the 100th email in this thread.

I think we broke Gmail's threading interface.

I want my $100 now.

Re: Tweaking the release procedure

[Randall Leeds <ra...@gmail.com>]

On Sat, Oct 22, 2011 at 22:50, Randall Leeds <ra...@gmail.com>wrote:

>
>
> On Sat, Oct 22, 2011 at 18:53, Paul Davis <pa...@gmail.com>wrote:
>
>> On Sat, Oct 22, 2011 at 3:17 PM, Randall Leeds <ra...@gmail.com>
>> wrote:
>> > On Sat, Oct 22, 2011 at 11:00, Noah Slater <ns...@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 <rn...@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 <pe...@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 <re...@...>
> 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
>

Re: Tweaking the release procedure

[Randall Leeds <ra...@gmail.com>]

On Sat, Oct 22, 2011 at 18:53, Paul Davis <pa...@gmail.com>wrote:

> On Sat, Oct 22, 2011 at 3:17 PM, Randall Leeds <ra...@gmail.com>
> wrote:
> > On Sat, Oct 22, 2011 at 11:00, Noah Slater <ns...@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 <rn...@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 <pe...@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 <re...@...>
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

Re: Tweaking the release procedure

[Paul Davis <pa...@gmail.com>]

On Sat, Oct 22, 2011 at 3:17 PM, Randall Leeds <ra...@gmail.com> wrote:
> On Sat, Oct 22, 2011 at 11:00, Noah Slater <ns...@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 <rn...@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 <pe...@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.

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.

>
> It's difficult to articulate my delight with this thread.
> Cheers all.
>
> Randall
>
> * This is the current limitations of infrastructure accountability leaking.
> + Infrastructure should work toward tooling that ties vote closure to
> tag pushing more seamlessly.
>
> [1] http://www.mjmwired.net/kernel/Documentation/SubmittingPatches#409
>

Re: Tweaking the release procedure

[Randall Leeds <ra...@gmail.com>]

On Sat, Oct 22, 2011 at 11:00, Noah Slater <ns...@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 <rn...@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 <pe...@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.

It's difficult to articulate my delight with this thread.
Cheers all.

Randall

* This is the current limitations of infrastructure accountability leaking.
+ Infrastructure should work toward tooling that ties vote closure to
tag pushing more seamlessly.

[1] http://www.mjmwired.net/kernel/Documentation/SubmittingPatches#409

Re: Tweaking the release procedure

[Noah Slater <ns...@tumbolia.org>]

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 <rn...@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.


> 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.


> 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.

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

Re: Tweaking the release procedure

[Robert Newson <rn...@apache.org>]

To Jason:

"That sounds like a tag by another name."

Yes, exactly. The point is that the thing I'm attempting a release
from already has a universally agreed and unambiguous name already, so
let's use it.

To Everyone:

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.

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.

Is there a complete alternate proposal to the 'only tag the release at
the end'? Do we feel we're close to finding one?

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.

B.

On 22 October 2011 06:19, Dustin Sallings <du...@spy.net> wrote:
>
> On Oct 21, 2011, at 9:08 PM, Noah Slater wrote:
>
>> Because 1.1 might have features in it that 1.2 does not. Or 1.1 might have a
>> security problem that 1.2 does not.  As Adam points out, there are many small
>> changes to files such as CHANGES or acinclude.in that are never
>> forward-ported. This kind of things goes on more than you might imagine. 1.1
>> is a branch of trunk, and it very likely has things in it that no future
>> branch will ever have. The lineage of CouchDB is not a big long line, one
>> release following on from another. It is much better to think of it as a
>> tree, with branches coming off from it.
>
>        I've never considered CHANGES, version numbers, or any other such thing that's managed by the revision control system as part of the source code, so I don't suffer these limitations in my projects.
>
>        I write my human readable changelog directly into my tag and also generate a commit log to go along with the release.  So, so many maintenance issues have gone away in every project I've done that in.
>
>        Consider my java memcached client.  The tag itself defines the tree version.  There is exactly *one* place where the number is defined.  The build system picks up that number and uses it to number itself.  While it's in there, it grabs the whole change log and makes it available via a command line:
>
>        https://gist.github.com/gists/1305645
>
>        The first file there is showing the output of introspection commands on the .jar itself.  The second is showing the tag the human typed up for release.  The source doesn't change when we branch.
>
>        memcached has similar things for autoconf.  The version number exists in only one place, so merging conflicts have nothing to do with administrative stuff.
>
>> Again, this assumes a linear progression of changes, which in reality does
>> not exist.
>
>        The only assumption I'm making is that you're not concurrently innovating on 1.1.x and 1.2.x and planning to maintain both forever.
>
>> I am not sure I understand this point. Are you suggesting that in order to
>> enforce an artificial linear progression of changes we should do fake noop
>> merges of any changesets applied to older release branches on to newer
>> release branches, even if those changes make no sense (such as updating a
>> line in acinclude.in) or apply to non-existent bits of code? I'm sorry, but
>> I m
>
>        Nope.  I'm suggesting that the set of changes contained within the "maintenance" branches and the "new" branches (as well as other "maintenance" branches) will continue to grow and you'll have to have tools or procedures to know what changes went into one place that didn't go into another.  I'd prefer to just say, "What's in 1.1 that's not in 1.2?" (a trivial commandline op) and have it tell me "nothing" most of the time.  A growing list that requires people to think about stuff makes it easier to make mistakes.
>
>        This strategy predates my git experience, but git only makes it easier.
>
>        I'm not talking about something particularly strange enough to be labeled "fake", but pulling it up from more to less firm trees means always knowing the state of things.  Things that don't apply have to be resolved.  A perfectly valid resolution is "just keep what I have".  The histories merge so you can note in the merge that the bug was in code that no longer exists, but you've *explicitly* done that in a machine trackable way.
>
>        We actually have the same kind of thing going on in memcached right now.  There are a lot of bugs fixed in the 1.4.x branch that don't exist (or are applied considerably differently) in 1.6.x.  Either way, I will record the 1.4 changes in the 1.6 history.
>
>> Again, this assumes a linear progression of changes. Like I said above, it's
>> more like a literal tree trunk, or perhaps a set of parallel universes.
>> Every time we cut a release branch, we're creating an alternate reality for
>> CouchDB. Most of these wither away. For a short time, we will back-port
>> fixes for them, or even apply fixes to them that never get forward ported.
>> But they are separate time-lines, and they need to be thought about and
>> managed as if that were the case. It's tricky at times, sure. But there are
>> tricker parts of the release process!
>
>
>        It's a graph.  Just because I can draw a line between two points on the graph doesn't mean that I think it's linear.  It really doesn't matter whether it's linear or if every couchdb contributor wrote a non-conflicting change at the same time and you did a 256-way octopus merge -- or anything in between.
>
>        At the end of the night, a single commit represents the head of a branch or the commit pointed to by the tag.  A merge-base exists between that and any other branch in your system and you have tools that can tell you all the things that are to the left or the right of that merge-base (or more if you're looking to do an n-way octopus merge across more than two -- I've done up to 24 myself).
>
>        I can do uni- or bi-directional set differences or just straight up diffs from either point and think about what the results mean.  In practice, I can't justify excluding changes from our 1.4 releases when we prep the 1.6 release.  It just gives me too much to think about (there are 444 new changes in one direction and 16 in the other).
>
> --
> dustin sallings
>
>
>
>

Re: Tweaking the release procedure

[Dustin Sallings <du...@spy.net>]

On Oct 21, 2011, at 9:08 PM, Noah Slater wrote:

> Because 1.1 might have features in it that 1.2 does not. Or 1.1 might have a
> security problem that 1.2 does not.  As Adam points out, there are many small
> changes to files such as CHANGES or acinclude.in that are never
> forward-ported. This kind of things goes on more than you might imagine. 1.1
> is a branch of trunk, and it very likely has things in it that no future
> branch will ever have. The lineage of CouchDB is not a big long line, one
> release following on from another. It is much better to think of it as a
> tree, with branches coming off from it.

	I've never considered CHANGES, version numbers, or any other such thing that's managed by the revision control system as part of the source code, so I don't suffer these limitations in my projects.

	I write my human readable changelog directly into my tag and also generate a commit log to go along with the release.  So, so many maintenance issues have gone away in every project I've done that in.

	Consider my java memcached client.  The tag itself defines the tree version.  There is exactly *one* place where the number is defined.  The build system picks up that number and uses it to number itself.  While it's in there, it grabs the whole change log and makes it available via a command line:

	https://gist.github.com/gists/1305645

	The first file there is showing the output of introspection commands on the .jar itself.  The second is showing the tag the human typed up for release.  The source doesn't change when we branch.

	memcached has similar things for autoconf.  The version number exists in only one place, so merging conflicts have nothing to do with administrative stuff.

> Again, this assumes a linear progression of changes, which in reality does
> not exist.

	The only assumption I'm making is that you're not concurrently innovating on 1.1.x and 1.2.x and planning to maintain both forever.

> I am not sure I understand this point. Are you suggesting that in order to
> enforce an artificial linear progression of changes we should do fake noop
> merges of any changesets applied to older release branches on to newer
> release branches, even if those changes make no sense (such as updating a
> line in acinclude.in) or apply to non-existent bits of code? I'm sorry, but
> I m

	Nope.  I'm suggesting that the set of changes contained within the "maintenance" branches and the "new" branches (as well as other "maintenance" branches) will continue to grow and you'll have to have tools or procedures to know what changes went into one place that didn't go into another.  I'd prefer to just say, "What's in 1.1 that's not in 1.2?" (a trivial commandline op) and have it tell me "nothing" most of the time.  A growing list that requires people to think about stuff makes it easier to make mistakes.

	This strategy predates my git experience, but git only makes it easier.

	I'm not talking about something particularly strange enough to be labeled "fake", but pulling it up from more to less firm trees means always knowing the state of things.  Things that don't apply have to be resolved.  A perfectly valid resolution is "just keep what I have".  The histories merge so you can note in the merge that the bug was in code that no longer exists, but you've *explicitly* done that in a machine trackable way.

	We actually have the same kind of thing going on in memcached right now.  There are a lot of bugs fixed in the 1.4.x branch that don't exist (or are applied considerably differently) in 1.6.x.  Either way, I will record the 1.4 changes in the 1.6 history.

> Again, this assumes a linear progression of changes. Like I said above, it's
> more like a literal tree trunk, or perhaps a set of parallel universes.
> Every time we cut a release branch, we're creating an alternate reality for
> CouchDB. Most of these wither away. For a short time, we will back-port
> fixes for them, or even apply fixes to them that never get forward ported.
> But they are separate time-lines, and they need to be thought about and
> managed as if that were the case. It's tricky at times, sure. But there are
> tricker parts of the release process!


	It's a graph.  Just because I can draw a line between two points on the graph doesn't mean that I think it's linear.  It really doesn't matter whether it's linear or if every couchdb contributor wrote a non-conflicting change at the same time and you did a 256-way octopus merge -- or anything in between.

	At the end of the night, a single commit represents the head of a branch or the commit pointed to by the tag.  A merge-base exists between that and any other branch in your system and you have tools that can tell you all the things that are to the left or the right of that merge-base (or more if you're looking to do an n-way octopus merge across more than two -- I've done up to 24 myself).

	I can do uni- or bi-directional set differences or just straight up diffs from either point and think about what the results mean.  In practice, I can't justify excluding changes from our 1.4 releases when we prep the 1.6 release.  It just gives me too much to think about (there are 444 new changes in one direction and 16 in the other).

-- 
dustin sallings

Re: Tweaking the release procedure

[Noah Slater <ns...@tumbolia.org>]

On Sat, Oct 22, 2011 at 5:08 AM, Noah Slater <ns...@tumbolia.org> wrote:

I'm sorry, but I m
>

This was actually my client messing things up, but I think I prefer it like
this, so I won't correct it.

Re: Tweaking the release procedure

[Noah Slater <ns...@tumbolia.org>]

On Sat, Oct 22, 2011 at 3:25 AM, Dustin Sallings <du...@spy.net> wrote:

This makes sense if 1.1.1 was released after 1.2, but why would you not want
> to include the 1.1 changes in 1.2?  As much as I dislike using perforce and
> its like, I find Laura Wingerd's Tofu Scale to be a good generally working
> model.
>

Because 1.1 might have features in it that 1.2 does not. Or 1.1 might have a
security problem that 1.2 does not. As Adam points out, there are many small
changes to files such as CHANGES or acinclude.in that are never
forward-ported. This kind of things goes on more than you might imagine. 1.1
is a branch of trunk, and it very likely has things in it that no future
branch will ever have. The lineage of CouchDB is not a big long line, one
release following on from another. It is much better to think of it as a
tree, with branches coming off from it.


> For example, let's say 1.1 is stable, released version of software and 1.2
> is a stabilizing, about to be released piece of software.  A bug fix that is
> important enough to require a fix in the previously released version should
> also be required for 1.2.  Ideally, you make the fix in 1.2 (the firmest of
> branches), and then merge it up.
>

Again, this assumes a linear progression of changes, which in reality does
not exist.

       This is true even if the broken functionality no longer exists,
> because it very clearly marks that the bug doesn't exist and how it came to
> not exist (git makes it easy to do what is effectively a NOOP merge).
>

I am not sure I understand this point. Are you suggesting that in order to
enforce an artificial linear progression of changes we should do fake noop
merges of any changesets applied to older release branches on to newer
release branches, even if those changes make no sense (such as updating a
line in acinclude.in) or apply to non-existent bits of code? I'm sorry, but
I m


> The end result is you can easily ask what's missing in either direction
> between any two points and nothing gets lost.  Show branch, github branch
> view, etc... will happily show you when a maintenance branch has crept ahead
> of a development branch.  Otherwise, it's a lot of work to ensure things
> don't get dropped.  I generally prefer to leverage the tools that can do
> this reliably for me.


Again, this assumes a linear progression of changes. Like I said above, it's
more like a literal tree trunk, or perhaps a set of parallel universes.
Every time we cut a release branch, we're creating an alternate reality for
CouchDB. Most of these wither away. For a short time, we will back-port
fixes for them, or even apply fixes to them that never get forward ported.
But they are separate time-lines, and they need to be thought about and
managed as if that were the case. It's tricky at times, sure. But there are
tricker parts of the release process!












I'm looking at you, GNU.

Re: Tweaking the release procedure

[Dustin Sallings <du...@spy.net>]

On Oct 21, 2011, at 5:42 PM, Noah Slater wrote:

> I don't follow this comment at all. 1.2 does not necessarily have everything
> 1.1 has in it. They may even diverge when we get down to the bugfix version.
> Releases are tagged from release branches which are split from trunk.
> Sometimes we apply fixes to the release branches that we do not
> "forward-port" to trunk or newer release branches. It's all there in the
> version control system. Can you clarify?


	This makes sense if 1.1.1 was released after 1.2, but why would you not want to include the 1.1 changes in 1.2?  As much as I dislike using perforce and its like, I find Laura Wingerd's Tofu Scale to be a good generally working model.

	For example, let's say 1.1 is stable, released version of software and 1.2 is a stabilizing, about to be released piece of software.  A bug fix that is important enough to require a fix in the previously released version should also be required for 1.2.  Ideally, you make the fix in 1.2 (the firmest of branches), and then merge it up.

	This is true even if the broken functionality no longer exists, because it very clearly marks that the bug doesn't exist and how it came to not exist (git makes it easy to do what is effectively a NOOP merge).

	The end result is you can easily ask what's missing in either direction between any two points and nothing gets lost.  Show branch, github branch view, etc... will happily show you when a maintenance branch has crept ahead of a development branch.  Otherwise, it's a lot of work to ensure things don't get dropped.  I generally prefer to leverage the tools that can do this reliably for me.

-- 
dustin sallings

Re: Tweaking the release procedure

[Noah Slater <ns...@tumbolia.org>]

On Sat, Oct 22, 2011 at 1:25 AM, Dustin Sallings <du...@spy.net> wrote:


> It would be terribly unfortunate if there was no trackable lineage between
> releases.  If version 1.2 does not contain version 1.1, then what does it
> contain?
>

I don't follow this comment at all. 1.2 does not necessarily have everything
1.1 has in it. They may even diverge when we get down to the bugfix version.
Releases are tagged from release branches which are split from trunk.
Sometimes we apply fixes to the release branches that we do not
"forward-port" to trunk or newer release branches. It's all there in the
version control system. Can you clarify?

Re: Tweaking the release procedure

[Dustin Sallings <du...@spy.net>]

On Oct 21, 2011, at 4:52 PM, Adam Kocoloski wrote:

> `git describe` would read something like 1.1.0-N-deadbeef, where N is the number of commits since the last tag.  On .0 releases it would probably just be the commit hash since the commit would not be a descendant of any tags.  It's a neat tool but I think it might confuse more than illuminate.

	It would be terribly unfortunate if there was no trackable lineage between releases.  If version 1.2 does not contain version 1.1, then what does it contain?

-- 
dustin sallings

Re: Tweaking the release procedure

[Adam Kocoloski <ko...@apache.org>]

On Oct 21, 2011, at 6:06 PM, Noah Slater wrote:

> On Fri, Oct 21, 2011 at 10:23 PM, Robert Newson <rn...@apache.org> wrote:
> 
>> Here's another suggestion.
>> 
>> In all vote emails, we include the commit id that the release
>> artifacts were built from, but create no tag at all.
>> 
>> When the release passes the votes, we create the tag, with its final
>> name, against that commit id, and push it at the same time we upload
>> the artifact to the mirrors.
>> 
>> To obviate any concern about stale 1.1.1 tags in downstream repos, we
>> could, for this release only, add a 1.1.1-final tag as an unambiguous
>> tag, but only *after* the release is official.
>> 
>> Stated another way; we make each tag exactly once, and refer to the
>> build by its commit id until then. Since a commit id in git dictates
>> the precise state of the entire tree this is safe.
> 
> 
> I love it when something is so obvious you wonder why it wasn't apparent in
> the first place. I love this suggestion, and the specifics of how you
> communicate the git commit hash is unimportant. If there's a "describe"
> command to make it easier, so be it. We only tag when we mean to tag a
> release, for reals.
> 
> As for the existing Git tags, I don't want to mess things up with a
> 1.1.1-final tag. Let's just accept the fact that some downstream
> repositories may have stale 1.1.1 tags from the previous two rounds, and go
> ahead and delete them. Once the vote passes on 1.1.1, we create a "1.1.1"
> tag as per this suggestion and request that people update their downstream
> git repos to make up for the fact we've now solidified our release procedure
> in a way that means those old tags need to be deleted. Make sense?

`git describe` would read something like 1.1.0-N-deadbeef, where N is the number of commits since the last tag.  On .0 releases it would probably just be the commit hash since the commit would not be a descendant of any tags.  It's a neat tool but I think it might confuse more than illuminate.

I'm ambivalent about using the commit hashes directly.  I'd rather use the vote/ or -vote style tags; I don't really share the concerns about cluttering up the tag namespace down the line, and if it does get annoyingly cluttered I'm fine deleting the old vote tags.  But it sounds like you find it to be pretty elegant, so I'm happy to go along.  Cheers,

Adam

Re: Tweaking the release procedure

[Noah Slater <ns...@tumbolia.org>]

On Fri, Oct 21, 2011 at 10:23 PM, Robert Newson <rn...@apache.org> wrote:

> Here's another suggestion.
>
> In all vote emails, we include the commit id that the release
> artifacts were built from, but create no tag at all.
>
> When the release passes the votes, we create the tag, with its final
> name, against that commit id, and push it at the same time we upload
> the artifact to the mirrors.
>
> To obviate any concern about stale 1.1.1 tags in downstream repos, we
> could, for this release only, add a 1.1.1-final tag as an unambiguous
> tag, but only *after* the release is official.
>
> Stated another way; we make each tag exactly once, and refer to the
> build by its commit id until then. Since a commit id in git dictates
> the precise state of the entire tree this is safe.


I love it when something is so obvious you wonder why it wasn't apparent in
the first place. I love this suggestion, and the specifics of how you
communicate the git commit hash is unimportant. If there's a "describe"
command to make it easier, so be it. We only tag when we mean to tag a
release, for reals.

As for the existing Git tags, I don't want to mess things up with a
1.1.1-final tag. Let's just accept the fact that some downstream
repositories may have stale 1.1.1 tags from the previous two rounds, and go
ahead and delete them. Once the vote passes on 1.1.1, we create a "1.1.1"
tag as per this suggestion and request that people update their downstream
git repos to make up for the fact we've now solidified our release procedure
in a way that means those old tags need to be deleted. Make sense?

Re: Tweaking the release procedure

[Robert Newson <rn...@apache.org>]

Here's another suggestion.

In all vote emails, we include the commit id that the release
artifacts were built from, but create no tag at all.

When the release passes the votes, we create the tag, with its final
name, against that commit id, and push it at the same time we upload
the artifact to the mirrors.

To obviate any concern about stale 1.1.1 tags in downstream repos, we
could, for this release only, add a 1.1.1-final tag as an unambiguous
tag, but only *after* the release is official.

Stated another way; we make each tag exactly once, and refer to the
build by its commit id until then. Since a commit id in git dictates
the precise state of the entire tree this is safe.

B.

On 21 October 2011 22:06, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
>
> On Fri, Oct 21, 2011 at 6:33 PM, Paul Davis <pa...@gmail.com> wrote:
>> Are there projects that do this version incrementing when a vote
>> fails? That's an idea I haven't heard before.
>
> I learned it from httpd (there's plenty of version number gaps at
> http://archive.apache.org/dist/httpd/). We use it also at Jackrabbit.
>
> BR,
>
> Jukka Zitting
>

Re: Tweaking the release procedure

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Fri, Oct 21, 2011 at 6:33 PM, Paul Davis <pa...@gmail.com> wrote:
> Are there projects that do this version incrementing when a vote
> fails? That's an idea I haven't heard before.

I learned it from httpd (there's plenty of version number gaps at
http://archive.apache.org/dist/httpd/). We use it also at Jackrabbit.

BR,

Jukka Zitting

Re: Tweaking the release procedure

[Robert Newson <rn...@apache.org>]

If other projects jumped off a cliff, would couch? I, for one, say no.

B.

On 21 October 2011 17:33, Paul Davis <pa...@gmail.com> wrote:
> On Fri, Oct 21, 2011 at 4:28 AM, Jukka Zitting <ju...@gmail.com> wrote:
>> Hi,
>>
>> My 2c from the gallery. I'm not involved in CouchDB, so just making
>> general observations from the perspective of other Apache projects
>> interested in using Git.
>>
>> On Fri, Oct 21, 2011 at 5:51 AM, Paul Davis <pa...@gmail.com> wrote:
>>> As Noah points out, there are ASF procedural issues that affect this
>>> discussion. Part of making a release involves getting community input
>>> on whether the release is a valid artefact. As such we need to be able
>>> to refer to these "not-release" sets of bytes.
>>
>> I'd say that's a perfectly valid use of tags. An official release
>> should be backed by a tag, but there's no requirement for the reverse.
>> Using tags for release candidates or other milestones should also be
>> fine. It should be up to each project to decide how they want to name
>> and manage tags.
>>
>> I also find the idea of renaming a release tag after the vote
>> completes a bit troublesome. The way I see it, a release manager will
>> tag a given state of the source tree and use that tag to build the
>> release candidate. After that no repository changes should be required
>> regardless of the result of the release vote. If the vote passes, the
>> candidate packages are pushed to www.apache.org/dist as-is. Otherwise
>> the release candidate is just dropped and the next one made.
>>
>> This kind of a workflow also solves the "1.1.1 vs. 1.1.1-rc1" problem.
>> If each release candidate is given a separate new tag and version
>> number (i.e. "1.1.1 vs 1.1.2"), then there can be no confusion about
>> which build is being tested. Version numbers are cheap.
>>
>> BR,
>>
>> Jukka Zitting
>>
>
> Are there projects that do this version incrementing when a vote
> fails? That's an idea I haven't heard before.
>

Re: Tweaking the release procedure

[Paul Davis <pa...@gmail.com>]

On Fri, Oct 21, 2011 at 4:28 AM, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
>
> My 2c from the gallery. I'm not involved in CouchDB, so just making
> general observations from the perspective of other Apache projects
> interested in using Git.
>
> On Fri, Oct 21, 2011 at 5:51 AM, Paul Davis <pa...@gmail.com> wrote:
>> As Noah points out, there are ASF procedural issues that affect this
>> discussion. Part of making a release involves getting community input
>> on whether the release is a valid artefact. As such we need to be able
>> to refer to these "not-release" sets of bytes.
>
> I'd say that's a perfectly valid use of tags. An official release
> should be backed by a tag, but there's no requirement for the reverse.
> Using tags for release candidates or other milestones should also be
> fine. It should be up to each project to decide how they want to name
> and manage tags.
>
> I also find the idea of renaming a release tag after the vote
> completes a bit troublesome. The way I see it, a release manager will
> tag a given state of the source tree and use that tag to build the
> release candidate. After that no repository changes should be required
> regardless of the result of the release vote. If the vote passes, the
> candidate packages are pushed to www.apache.org/dist as-is. Otherwise
> the release candidate is just dropped and the next one made.
>
> This kind of a workflow also solves the "1.1.1 vs. 1.1.1-rc1" problem.
> If each release candidate is given a separate new tag and version
> number (i.e. "1.1.1 vs 1.1.2"), then there can be no confusion about
> which build is being tested. Version numbers are cheap.
>
> BR,
>
> Jukka Zitting
>

Are there projects that do this version incrementing when a vote
fails? That's an idea I haven't heard before.

Re: Tweaking the release procedure

[Noah Slater <ns...@tumbolia.org>]

On Fri, Oct 21, 2011 at 10:28 AM, Jukka Zitting <ju...@gmail.com>wrote:


> I'd say that's a perfectly valid use of tags. An official release
> should be backed by a tag, but there's no requirement for the reverse.
> Using tags for release candidates or other milestones should also be
> fine. It should be up to each project to decide how they want to name
> and manage tags.
>

That depends. As far as I understand it from this thread, once you create a
tag, downstream repositories are likely to keep those tags around. So, is it
unreasonable to assume that temporary tags will start to accumulate in this
downstream repositories?

The problem here is in communicating to the end user which tags correspond
to officially blessed release artefacts. With Subversion, you just delete
the tag and recreate it, and there is no chance of confusion. Is
this possible with Git? We absolutely cannot allow any situation where a tag
corresponding to a failed vote is presented to the user along-side tags
corresponding to officially blessed release artefacts. And as far as I am
concerned, that needs to take in to account any behaviour of the Git
downstream repositories that people may be using.

I also find the idea of renaming a release tag after the vote
> completes a bit troublesome. The way I see it, a release manager will
> tag a given state of the source tree and use that tag to build the
> release candidate. After that no repository changes should be required
> regardless of the result of the release vote. If the vote passes, the
> candidate packages are pushed to www.apache.org/dist as-is. Otherwise
> the release candidate is just dropped and the next one made.
>

This only holds if there is a way to remove the failed tags. Either by
overwriting them, as we did with Subversion, or removing them in way that
removes them from another downstream repositories that users may be using.
If there is no way to do this, and my concern is shared by the community,
then we may have to adopt a procedure that involves "moving" a tag to a
blessed directory when the vote passes.


> This kind of a workflow also solves the "1.1.1 vs. 1.1.1-rc1" problem.
> If each release candidate is given a separate new tag and version
> number (i.e. "1.1.1 vs 1.1.2"), then there can be no confusion about
> which build is being tested. Version numbers are cheap.


Version numbers are only cheap if you're prepared to dilute what they mean.
At the moment the bugfix version number has a very precise meaning, and
there is a contract in place for when it is updated. Doing what you suggest
breaks that contract. I may not have mentioned this before, but I designed
the CouchDB versioning scheme, and I based it directly on the Apple
versioning scheme.

Read more about it here:

http://en.wikipedia.org/wiki/Software_versioning#Apple

Also, this doesn't solve our problem of failed vote tags persisting in
downstream repositories.

Re: Tweaking the release procedure

[Jukka Zitting <ju...@gmail.com>]

Hi,

My 2c from the gallery. I'm not involved in CouchDB, so just making
general observations from the perspective of other Apache projects
interested in using Git.

On Fri, Oct 21, 2011 at 5:51 AM, Paul Davis <pa...@gmail.com> wrote:
> As Noah points out, there are ASF procedural issues that affect this
> discussion. Part of making a release involves getting community input
> on whether the release is a valid artefact. As such we need to be able
> to refer to these "not-release" sets of bytes.

I'd say that's a perfectly valid use of tags. An official release
should be backed by a tag, but there's no requirement for the reverse.
Using tags for release candidates or other milestones should also be
fine. It should be up to each project to decide how they want to name
and manage tags.

I also find the idea of renaming a release tag after the vote
completes a bit troublesome. The way I see it, a release manager will
tag a given state of the source tree and use that tag to build the
release candidate. After that no repository changes should be required
regardless of the result of the release vote. If the vote passes, the
candidate packages are pushed to www.apache.org/dist as-is. Otherwise
the release candidate is just dropped and the next one made.

This kind of a workflow also solves the "1.1.1 vs. 1.1.1-rc1" problem.
If each release candidate is given a separate new tag and version
number (i.e. "1.1.1 vs 1.1.2"), then there can be no confusion about
which build is being tested. Version numbers are cheap.

BR,

Jukka Zitting

Re: Tweaking the release procedure

[Paul Davis <pa...@gmail.com>]

As Noah points out, there are ASF procedural issues that affect this
discussion. Part of making a release involves getting community input
on whether the release is a valid artefact. As such we need to be able
to refer to these "not-release" sets of bytes. Traditionally in SVN we
did this by creating and delting "tags". Though SVN's idea of tags is
pretty bad.

The current issue is how do we create general best-practice guidelines
for any ASF project that might be interested in using Git. A naming
scheme along with the specific ASF Git hosting code should be
considered to try and minimize the confusion across a theoretical
couple hundred projects employing a couple thousand committers.

>        In the above example, if someone downloaded and is currently running 1.1.1-rc1 and he looks at the list of tags and sees v1.1.1, v1.1.1-rc1 and v1.1.1-rc2, why would be confused?  More importantly, you released that, so why would you not want the user to be able to see whether any changes between 1.1.1-rc1 and 1.1.1 final affect his deployment?
>

You're missing my concern. My concern is when someone comes to us and
say's, "I'm running 1.1.1" and then I spend a couple hours debugging
that they really meant "I'm running 1.1.1-rc1." Anyone that's not
scared of this needs to spend more time debugging bugs in community
IRC channels or mailing lists.

>        The git git repo has 366 tags right now.  In addition to releases from a subproject that spun out, there are 337 tags representing releases (and RCs) that shipped.  It captures a wonderful release history of the project.
>
>        These are the tags since (and including) the version I'm running:
>
> v1.7.4.4        Git 1.7.4.4
> v1.7.4.5        Git 1.7.4.5
> v1.7.5          Git 1.7.5
> v1.7.5-rc0      Git 1.7.5-rc0
> v1.7.5-rc1      Git 1.7.5-rc1
> v1.7.5-rc2      Git 1.7.5-rc2
> v1.7.5-rc3      Git 1.7.5-rc3
> v1.7.5.1        Git 1.7.5.1
> v1.7.5.2        Git 1.7.5.2
> v1.7.5.3        Git 1.7.5.3
> v1.7.5.4        Git 1.7.5.4
> v1.7.6          Git 1.7.6
> v1.7.6-rc0      Git 1.7.6-rc0
> v1.7.6-rc1      Git 1.7.6-rc1
> v1.7.6-rc2      Git 1.7.6-rc2
> v1.7.6-rc3      Git 1.7.6-rc3
> v1.7.6.1        Git 1.7.6.1
> v1.7.7-rc0      Git 1.7.7-rc0
>
>        I very well may be biased, but I don't find that confusing.
>

Nor do I, but that is absolutely not the way to think about the issue.
Anyone on the dev@ list is pretty much categorically disqualified from
making a decision on what's best here. Of course if you follow such a
list you'll have an idea on what the "right" release is. But if you're
not involved, or even if you're not involved in dev of anything, its
not inconceivable (I do know what that word means :) to make the
mistake that 1.1.1-rc1 is newer than 1.1.1.

Re: Tweaking the release procedure

[Noah Slater <ns...@tumbolia.org>]

On Fri, Oct 21, 2011 at 2:04 AM, Dustin Sallings <du...@spy.net> wrote:

I've always considered anything I give out to be a release.  This includes
> betas and RCs and anything else.


It's important to clear up that this is NOT the case for Apache projects. A
release is a set of artefacts that have been successfully voted on by the
community and then released according to our official release procedure.
Anything else, including the artefacts we vote on that don't make the cut,
are not considered releases. And this isn't just a choice of wording either,
it's a very important distinction.

Anyone can prepare an artefact and put it up for the vote, but only
artefacts that pass the muster are considered releases. The term "release
candidate" is not an official term, and it is not defined in the ASF
literature or as part of the release process. It's probably a bad choice of
words too, as in other projects, a release candidate IS a sort of release
that is made by the project. We don't do that here.

Hope this clears things up!

Re: Tweaking the release procedure

[Paul Davis <pa...@gmail.com>]

On Thu, Oct 20, 2011 at 8:18 PM, Noah Slater <ns...@tumbolia.org> wrote:
> On Fri, Oct 21, 2011 at 2:04 AM, Dustin Sallings <du...@spy.net> wrote:
>
> v1.7.4.4        Git 1.7.4.4
>> v1.7.4.5        Git 1.7.4.5
>> v1.7.5          Git 1.7.5
>> v1.7.5-rc0      Git 1.7.5-rc0
>> v1.7.5-rc1      Git 1.7.5-rc1
>> v1.7.5-rc2      Git 1.7.5-rc2
>> v1.7.5-rc3      Git 1.7.5-rc3
>> v1.7.5.1        Git 1.7.5.1
>> v1.7.5.2        Git 1.7.5.2
>> v1.7.5.3        Git 1.7.5.3
>> v1.7.5.4        Git 1.7.5.4
>> v1.7.6          Git 1.7.6
>> v1.7.6-rc0      Git 1.7.6-rc0
>> v1.7.6-rc1      Git 1.7.6-rc1
>> v1.7.6-rc2      Git 1.7.6-rc2
>> v1.7.6-rc3      Git 1.7.6-rc3
>> v1.7.6.1        Git 1.7.6.1
>> v1.7.7-rc0      Git 1.7.7-rc0
>>
>>        I very well may be biased, but I don't find that confusing.
>
>
> Oh, and by extension, I will give my -1 vote to any system that mixes these
> two together. The release tag for X.Y.Z should be tied to an official
> artefact of the Apache CouchDB project. A tag that doesn't pass the vote
> should be deleted. The history is in the X.Y.x release branch. It has no
> business cluttering up the tags, and no business confusing users about
> whether it has been blessed by the project.
>

Hear hear. My thoughts on this were to try and add a simple convention
to enforce this. Merely by prefixing anything with "rel/" that would
signal an 'official blessing' on the subject in question. There are
any number of ways to do this, and I'm quite open to hearing
alternatives, but this is exactly what I was aiming at. We need a
procedural/community thing that says "these over here are pristine,
these over here are us fucking about."

In my slap dashery I chose the "rel/" prefix. There are definitely
other solutions, but I think Noah has hit the nail on the head in
pointing out the underlying need that we should be discussing.

Re: Tweaking the release procedure

[Benoit Chesneau <bc...@gmail.com>]

Just read about this thread this morning.

On Fri, Oct 21, 2011 at 3:18 AM, Noah Slater <ns...@tumbolia.org> wrote:
> On Fri, Oct 21, 2011 at 2:04 AM, Dustin Sallings <du...@spy.net> wrote:
>
> v1.7.4.4        Git 1.7.4.4
>> v1.7.4.5        Git 1.7.4.5
>> v1.7.5          Git 1.7.5
>> v1.7.5-rc0      Git 1.7.5-rc0
>> v1.7.5-rc1      Git 1.7.5-rc1
>> v1.7.5-rc2      Git 1.7.5-rc2
>> v1.7.5-rc3      Git 1.7.5-rc3
>> v1.7.5.1        Git 1.7.5.1
>> v1.7.5.2        Git 1.7.5.2
>> v1.7.5.3        Git 1.7.5.3
>> v1.7.5.4        Git 1.7.5.4
>> v1.7.6          Git 1.7.6
>> v1.7.6-rc0      Git 1.7.6-rc0
>> v1.7.6-rc1      Git 1.7.6-rc1
>> v1.7.6-rc2      Git 1.7.6-rc2
>> v1.7.6-rc3      Git 1.7.6-rc3
>> v1.7.6.1        Git 1.7.6.1
>> v1.7.7-rc0      Git 1.7.7-rc0
>>
>>        I very well may be biased, but I don't find that confusing.
>
>
> Oh, and by extension, I will give my -1 vote to any system that mixes these
> two together. The release tag for X.Y.Z should be tied to an official
> artefact of the Apache CouchDB project. A tag that doesn't pass the vote
> should be deleted. The history is in the X.Y.x release branch. It has no
> business cluttering up the tags, and no business confusing users about
> whether it has been blessed by the project.
>

if we where going to something "semantic", then it should probably be
rc1.1.x and v1.1.x ...  Though I don't like it so much, and it's not
really used around. (also just because a buzz around a semver page has
been done doesn't mean it should be used).

X.X.X for stable version and X.X.X-rcX for release control ? Having
tag looking like blah/X.X.X sounds odd . I'm not sure we need to
reinvent the wold.

About messages in releases and tag I never read them, but couldn't it
simply summarize the vote? CHANGES is better to read release notes ,
also this is the thing that is distributed in the archive.

my 2 cents,

- benoît

http://www.youtube.com/watch?v=brOWtKkHo1M
- benoît

Re: Tweaking the release procedure

[Dustin Sallings <du...@spy.net>]

On Oct 20, 2011, at 9:03 PM, Paul Davis wrote:

> Your argument here and the earlier argument about branches being
> temporary tags confuses me. Both are nothing more than pointers at
> hashes. This is just a social distinction. This entire thread is
> considering social distinctions about community consensus to decide
> what will be the value of the 1.1.1 (for immediate reference) tag.


	Tags and branches are considerably different things with different uses.

	A tag is a first class object with a creator, timestamp, message, and optional GPG signature with a corresponding ref.  It points to a commit (though it *can* point to other objects,  you generally don't do that).  A branch is just a symbolic ref pointing to a commit.

	Tags objects are generally harder to get rid of than branches.  Upstream tag deletions aren't propagated downstream on normal clones (for good reason described in the tag documentation).  Anyone who clones your repo and updates his clone will most surely receive your new tag and you will have to ask him to do extra work to remove the tag when you delete it.  That's just not practical since you can't even know who has cloned your repo.  (try it -- create an "upstream repo", clone it, tag it, update your clone (pull, etc...), remove the tag and try to convince the clone to care without manually deleting it there, too)

	Branches, however, at least do have 'git remote update -p' to prune away any local mirrors of upstream refs when you remove them.


	Tags are, in practice, permanent pointers to important points in the history of the project.  Branches are named pointers to development locations.  They're often ephemeral (feature branches are common) and are generally meant to be treated the way you're describing "rc tags".

	Again, I don't really have much of a dog in the fight here.  I'm just suggesting that creating conventions that are different from what the tools are accustomed to, you might find some technical difficulties you'd otherwise avoid.

-- 
dustin sallings

Re: Tweaking the release procedure

[Paul Davis <pa...@gmail.com>]

On Thu, Oct 20, 2011 at 10:01 PM, Dustin Sallings <du...@spy.net> wrote:
>
> On Oct 20, 2011, at 6:18 PM, Noah Slater wrote:
>
>> The history is in the X.Y.x release branch. It has no
>> business cluttering up the tags, and no business confusing users about
>> whether it has been blessed by the project.
>
>
>        Does this imply you intend to leave branches open forever even when development on them has stopped?
>
>        I would say that the history is in the commits that lead up to the tag along with the release notes being actually *in* the tag.
>
>        I've seen people keep lots of dead branches around which I find considerably more confusing than excessive tags since a branch is a dynamic line of development and a tag is a static commit in time.  If you're not actively doing development, a branch just makes it look like you might be.
>
>        It's trivial (in git at least) to reopen a development branch from any previously released version with cryptographically verified certainty that you have the correct code that led to that release.
>

Your argument here and the earlier argument about branches being
temporary tags confuses me. Both are nothing more than pointers at
hashes. This is just a social distinction. This entire thread is
considering social distinctions about community consensus to decide
what will be the value of the 1.1.1 (for immediate reference) tag.

Consider each release a single round of Paxos to generate distributed
consensus on which sha to choose.

>
>        Not that I think you guys don't know what you're doing or anything.  I'm coming mostly from a "user" who will be hoping to be using couchdb sources, writing extensions, and trying hard to make sure whatever changes I make are made available to all couchdb users and developers.  That and I've got a ridiculous amount of time spent manipulating git repos.
>
> --
> dustin sallings
>
>
>
>

Re: Tweaking the release procedure

[Dustin Sallings <du...@spy.net>]

On Oct 20, 2011, at 6:18 PM, Noah Slater wrote:

> The history is in the X.Y.x release branch. It has no
> business cluttering up the tags, and no business confusing users about
> whether it has been blessed by the project.


	Does this imply you intend to leave branches open forever even when development on them has stopped?

	I would say that the history is in the commits that lead up to the tag along with the release notes being actually *in* the tag. 

	I've seen people keep lots of dead branches around which I find considerably more confusing than excessive tags since a branch is a dynamic line of development and a tag is a static commit in time.  If you're not actively doing development, a branch just makes it look like you might be.

	It's trivial (in git at least) to reopen a development branch from any previously released version with cryptographically verified certainty that you have the correct code that led to that release.


	Not that I think you guys don't know what you're doing or anything.  I'm coming mostly from a "user" who will be hoping to be using couchdb sources, writing extensions, and trying hard to make sure whatever changes I make are made available to all couchdb users and developers.  That and I've got a ridiculous amount of time spent manipulating git repos.

-- 
dustin sallings

Re: Tweaking the release procedure

[Noah Slater <ns...@tumbolia.org>]

On Fri, Oct 21, 2011 at 2:04 AM, Dustin Sallings <du...@spy.net> wrote:

v1.7.4.4        Git 1.7.4.4
> v1.7.4.5        Git 1.7.4.5
> v1.7.5          Git 1.7.5
> v1.7.5-rc0      Git 1.7.5-rc0
> v1.7.5-rc1      Git 1.7.5-rc1
> v1.7.5-rc2      Git 1.7.5-rc2
> v1.7.5-rc3      Git 1.7.5-rc3
> v1.7.5.1        Git 1.7.5.1
> v1.7.5.2        Git 1.7.5.2
> v1.7.5.3        Git 1.7.5.3
> v1.7.5.4        Git 1.7.5.4
> v1.7.6          Git 1.7.6
> v1.7.6-rc0      Git 1.7.6-rc0
> v1.7.6-rc1      Git 1.7.6-rc1
> v1.7.6-rc2      Git 1.7.6-rc2
> v1.7.6-rc3      Git 1.7.6-rc3
> v1.7.6.1        Git 1.7.6.1
> v1.7.7-rc0      Git 1.7.7-rc0
>
>        I very well may be biased, but I don't find that confusing.


Oh, and by extension, I will give my -1 vote to any system that mixes these
two together. The release tag for X.Y.Z should be tied to an official
artefact of the Apache CouchDB project. A tag that doesn't pass the vote
should be deleted. The history is in the X.Y.x release branch. It has no
business cluttering up the tags, and no business confusing users about
whether it has been blessed by the project.

Re: Tweaking the release procedure

[Dustin Sallings <du...@spy.net>]

On Oct 20, 2011, at 10:51 AM, Paul Davis wrote:

> Yes, the "path" prefixes (path probably was a bard word in my original
> email) exists merely as a way to distinguish between "these are
> official releases and are immutable" and the "this is a temporary tag
> that I can fix if I screw up."

	Branches really make the best temporary tags.

> I'm trying to consider all the cases here (in the context of my OCD).
> Do we necessarily care about the rc tags once a release has been made?
> In a perfect world I would expect one tag per release and everything
> would be neat and tidy. If so, then we need to be able to remove old
> tags once they have been usurped by actual releases.

	I've always considered anything I give out to be a release.  This includes betas and RCs and anything else.

> Consider it from the POV of a user as well. If you have 5-10 tags for
> a release (not out of the question) then each user looking for that
> release has to spend time figuring out which is the right tag. Which
> means that either our naming conventions have to be extremely clear
> (even then I've seen enough to know that we'll still get questions) or
> we need to have procedure to narrow down the set of tags once the
> release is made. I prefer procedure because it will minimize the
> number of times in the future that i have to spend time debugging the
> fact that someone downloaded 1.1.1-rc1 instead of 1.1.1 which has that
> bug related to SpiderMonkey 1.7 and sealing.

	This is why semver suggests version and tag naming conventions.  There's just no confusion if the version number and the tag number match.

	In the above example, if someone downloaded and is currently running 1.1.1-rc1 and he looks at the list of tags and sees v1.1.1, v1.1.1-rc1 and v1.1.1-rc2, why would be confused?  More importantly, you released that, so why would you not want the user to be able to see whether any changes between 1.1.1-rc1 and 1.1.1 final affect his deployment?

	The git git repo has 366 tags right now.  In addition to releases from a subproject that spun out, there are 337 tags representing releases (and RCs) that shipped.  It captures a wonderful release history of the project.

	These are the tags since (and including) the version I'm running:

v1.7.4.4        Git 1.7.4.4
v1.7.4.5        Git 1.7.4.5
v1.7.5          Git 1.7.5
v1.7.5-rc0      Git 1.7.5-rc0
v1.7.5-rc1      Git 1.7.5-rc1
v1.7.5-rc2      Git 1.7.5-rc2
v1.7.5-rc3      Git 1.7.5-rc3
v1.7.5.1        Git 1.7.5.1
v1.7.5.2        Git 1.7.5.2
v1.7.5.3        Git 1.7.5.3
v1.7.5.4        Git 1.7.5.4
v1.7.6          Git 1.7.6
v1.7.6-rc0      Git 1.7.6-rc0
v1.7.6-rc1      Git 1.7.6-rc1
v1.7.6-rc2      Git 1.7.6-rc2
v1.7.6-rc3      Git 1.7.6-rc3
v1.7.6.1        Git 1.7.6.1
v1.7.7-rc0      Git 1.7.7-rc0

	I very well may be biased, but I don't find that confusing.

-- 
dustin sallings

Re: Tweaking the release procedure

[Paul Davis <pa...@gmail.com>]

On Wed, Oct 19, 2011 at 10:10 PM, Adam Kocoloski
<ad...@gmail.com> wrote:
> On Oct 19, 2011, at 10:53 PM, Dustin Sallings <du...@spy.net> wrote:
>
>>
>> On Oct 19, 2011, at 6:56 PM, Adam Kocoloski wrote:
>>
>>> I think you might be reading a bit too much into what Noah is saying here.  I believe he's just taking issue with the two separate rc/ and rel/ "paths" in the tag names.  For what it's worth I agree with him on that front, though I'd consider going even further (as Paul suggested earlier in the thread) and just prevent rewriting of any tag pushed to the ASF remote.  Then there's no need for any tag prefix at all.  Best,
>>
>>
>>    I don't think that's different from what I said.  Tags don't generally have "paths" (it's 1.4rc1 or it isn't) and git makes it hard to overwrite them because it's a bad idea and will only lead to confusion.
>>
>>    IMO, there just isn't room or need to innovate here.  Code's cooked in various dev branches.  That gets rolled up into an "official" branch towards a feature or release.  Once a release is almost ready, alpha, beta and RC tags get dropped in aligned with the same version numbers the server will report.  Once it's done, you can retag a commit with a newer tag that calls it done and it's shipped.
>>
>> --
>> dustin sallings
>
> Git makes it hard, but by no means impossible.  The whole reason these "paths" are even on the table is to add some immutability to the official ASF repo.  A little less convention, a little more configuration.  Best,
>
> Adam

Yes, the "path" prefixes (path probably was a bard word in my original
email) exists merely as a way to distinguish between "these are
official releases and are immutable" and the "this is a temporary tag
that I can fix if I screw up."

I'm trying to consider all the cases here (in the context of my OCD).
Do we necessarily care about the rc tags once a release has been made?
In a perfect world I would expect one tag per release and everything
would be neat and tidy. If so, then we need to be able to remove old
tags once they have been usurped by actual releases.

Consider it from the POV of a user as well. If you have 5-10 tags for
a release (not out of the question) then each user looking for that
release has to spend time figuring out which is the right tag. Which
means that either our naming conventions have to be extremely clear
(even then I've seen enough to know that we'll still get questions) or
we need to have procedure to narrow down the set of tags once the
release is made. I prefer procedure because it will minimize the
number of times in the future that i have to spend time debugging the
fact that someone downloaded 1.1.1-rc1 instead of 1.1.1 which has that
bug related to SpiderMonkey 1.7 and sealing.

Re: Tweaking the release procedure

[Adam Kocoloski <ad...@gmail.com>]

On Oct 19, 2011, at 10:53 PM, Dustin Sallings <du...@spy.net> wrote:

> 
> On Oct 19, 2011, at 6:56 PM, Adam Kocoloski wrote:
> 
>> I think you might be reading a bit too much into what Noah is saying here.  I believe he's just taking issue with the two separate rc/ and rel/ "paths" in the tag names.  For what it's worth I agree with him on that front, though I'd consider going even further (as Paul suggested earlier in the thread) and just prevent rewriting of any tag pushed to the ASF remote.  Then there's no need for any tag prefix at all.  Best,
> 
> 
>    I don't think that's different from what I said.  Tags don't generally have "paths" (it's 1.4rc1 or it isn't) and git makes it hard to overwrite them because it's a bad idea and will only lead to confusion.
> 
>    IMO, there just isn't room or need to innovate here.  Code's cooked in various dev branches.  That gets rolled up into an "official" branch towards a feature or release.  Once a release is almost ready, alpha, beta and RC tags get dropped in aligned with the same version numbers the server will report.  Once it's done, you can retag a commit with a newer tag that calls it done and it's shipped.
> 
> -- 
> dustin sallings

Git makes it hard, but by no means impossible.  The whole reason these "paths" are even on the table is to add some immutability to the official ASF repo.  A little less convention, a little more configuration.  Best,

Adam

Re: Tweaking the release procedure

[Dustin Sallings <du...@spy.net>]

On Oct 19, 2011, at 6:56 PM, Adam Kocoloski wrote:

> I think you might be reading a bit too much into what Noah is saying here.  I believe he's just taking issue with the two separate rc/ and rel/ "paths" in the tag names.  For what it's worth I agree with him on that front, though I'd consider going even further (as Paul suggested earlier in the thread) and just prevent rewriting of any tag pushed to the ASF remote.  Then there's no need for any tag prefix at all.  Best,


	I don't think that's different from what I said.  Tags don't generally have "paths" (it's 1.4rc1 or it isn't) and git makes it hard to overwrite them because it's a bad idea and will only lead to confusion.

	IMO, there just isn't room or need to innovate here.  Code's cooked in various dev branches.  That gets rolled up into an "official" branch towards a feature or release.  Once a release is almost ready, alpha, beta and RC tags get dropped in aligned with the same version numbers the server will report.  Once it's done, you can retag a commit with a newer tag that calls it done and it's shipped.

-- 
dustin sallings

Re: Tweaking the release procedure

[Adam Kocoloski <ko...@apache.org>]

On Oct 19, 2011, at 9:04 PM, Dustin Sallings wrote:

> 
> On Oct 19, 2011, at 2:33 PM, Noah Slater wrote:
> 
>> Why not just have a top level tags/ directory that prevents rewriting. In
>> that you'd tag a release candidate as X.Y.Z-rc1, X.Y.Z-rc2, etc until a vote
>> passed, at which point, you copy the tag to X.Y.Z. I don't see a need
>> to separate these out with a second level directory.
> 
> 
> 	Probably best to not consider tags as svn refers to them.  It's not a copy, just a pointer to a commit that was the last one in the release (which, in turn, points to the commits that preceded it).
> 
> 	In git, tags generally get a ref prefix of refs/tags/ (it's more of a namespace than a directory).  I'd recommend not doing anything different from what git will give you out of the box.  Tag your rc, tag it again when it becomes a release.
> 
> 	Tags are intentionally hard to rid yourself of in git.  Once you publish a "this is 2.5", getting a second chance requires coordination.  You can overwrite them locally, of course, but once they're published and replicated, the down streams basically have to agrees to move.
> 
> 	I'm a bit of a bystander, but I'd really want to see strong justification for not wanting to use git's normal tools and methodologies.
> 
> -- 
> dustin sallings

I think you might be reading a bit too much into what Noah is saying here.  I believe he's just taking issue with the two separate rc/ and rel/ "paths" in the tag names.  For what it's worth I agree with him on that front, though I'd consider going even further (as Paul suggested earlier in the thread) and just prevent rewriting of any tag pushed to the ASF remote.  Then there's no need for any tag prefix at all.  Best,

Adam

Re: Tweaking the release procedure

[Dustin Sallings <du...@spy.net>]

On Oct 19, 2011, at 2:33 PM, Noah Slater wrote:

> Why not just have a top level tags/ directory that prevents rewriting. In
> that you'd tag a release candidate as X.Y.Z-rc1, X.Y.Z-rc2, etc until a vote
> passed, at which point, you copy the tag to X.Y.Z. I don't see a need
> to separate these out with a second level directory.


	Probably best to not consider tags as svn refers to them.  It's not a copy, just a pointer to a commit that was the last one in the release (which, in turn, points to the commits that preceded it).

	In git, tags generally get a ref prefix of refs/tags/ (it's more of a namespace than a directory).  I'd recommend not doing anything different from what git will give you out of the box.  Tag your rc, tag it again when it becomes a release.

	Tags are intentionally hard to rid yourself of in git.  Once you publish a "this is 2.5", getting a second chance requires coordination.  You can overwrite them locally, of course, but once they're published and replicated, the down streams basically have to agrees to move.

	I'm a bit of a bystander, but I'd really want to see strong justification for not wanting to use git's normal tools and methodologies.

-- 
dustin sallings

Re: Tweaking the release procedure

[Noah Slater <ns...@tumbolia.org>]

I'm a git luddite, so please excuse any obviously barbarous things I might
say.

On Wed, Oct 19, 2011 at 5:55 PM, Paul Davis <pa...@gmail.com>wrote:

1. When tagging release candidates, the tag would be of the pattern:
>
>     tags/rc/X.Y.Z-rcN
>
> 2. When a release formally passes a vote, we would copy the tag to:
>
>     tags/rel/X.Y.Z
>

This strikes me as being needlessly complex.

Why not just have a top level tags/ directory that prevents rewriting. In
that you'd tag a release candidate as X.Y.Z-rc1, X.Y.Z-rc2, etc until a vote
passed, at which point, you copy the tag to X.Y.Z. I don't see a need
to separate these out with a second level directory.


> 3. I think we discussed this before, but we should also place the rc
> artefacts into a directory named as such (IIRC, we decided that the
> name shouldn't change). Ie, 1.1.1 would be stored at:
>
> http://people.apache.org/~rnewson/dist/1.1.1/rc1/apache-couchdb-1.1.1.tar.gz


Same deal.

Let's keep the hierarchy flat and have it as dist/X.Y.Z-rc1 to match.


> 4. Making new release branches we should name them:
>
>    branches/rel/X.Y.x
>

Why the additional subdirectory here?

Is there anything causing problems with the old branches/X.Y.x scheme?


> 5. For continuity, I'd also propose copying all of our older tags and
> branches to the new pattern (while keeping the current versions around
> for an extended period of time).


Sure.

>

Re: Tweaking the release procedure

[Paul Davis <pa...@gmail.com>]

On Wed, Oct 19, 2011 at 1:29 PM, Dustin Sallings <du...@spy.net> wrote:
>
> On Oct 19, 2011, at 9:55 AM, Paul Davis wrote:
>
>> 1. When tagging release candidates, the tag would be of the pattern:
>>
>>     tags/rc/X.Y.Z-rcN
>>
>> 2. When a release formally passes a vote, we would copy the tag to:
>>
>>     tags/rel/X.Y.Z
>
>
>        is "git describe" happy with multiple tag locations?
>
> --
> dustin sallings
>
>
>
>

No idea how it'd choose between the two. Though I'm not sure I see an
issue deleting the rc/ tags once they're no longer valid.

Re: Tweaking the release procedure

[Dustin Sallings <du...@spy.net>]

On Oct 19, 2011, at 9:55 AM, Paul Davis wrote:

> 1. When tagging release candidates, the tag would be of the pattern:
> 
>     tags/rc/X.Y.Z-rcN
> 
> 2. When a release formally passes a vote, we would copy the tag to:
> 
>     tags/rel/X.Y.Z


	is "git describe" happy with multiple tag locations?

-- 
dustin sallings