couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Smith <...@iriscouch.com>
Subject Re: Tweaking the release procedure
Date Sat, 22 Oct 2011 04:38:38 GMT
On Sat, Oct 22, 2011 at 10:56 AM, Noah Slater <nslater@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

Mime
View raw message