couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randall Leeds <randall.le...@gmail.com>
Subject Re: Tweaking the release procedure
Date Sat, 22 Oct 2011 04:52:28 GMT
On Fri, Oct 21, 2011 at 21:38, Jason Smith <jhs@iriscouch.com> wrote:

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

+<3

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