On Fri, Oct 21, 2011 at 21:38, Jason Smith <[email protected]> wrote:
> On Sat, Oct 22, 2011 at 10:56 AM, Noah Slater <[email protected]> > 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
