On Sat, Oct 22, 2011 at 10:56 AM, Noah Slater <nsla...@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
