use lightweight tags on gerrit to provide moving codename targets

I think first step is just to try adding a symbolic-ref directly on one of the git repos on the filesystem and see if gerrit serves it/understands it properly if that works, probably a puppet script/yaml entry that makes the refs

Use cases:
 - soren would like to develop something based on "folsom" He would like to start developing that thing before folsom is released, so he would like to point his automated testing scripts to grab the folsom code base, build it, test it and deploy it. When folsom moves to milestone-proposed, his testing has to change and now pull milestone-proposed instead of master - although there is no technical signal to indicate this to him. Similarly, when it is released, stable/folsom is now the thing he would like to grab. If the opening of the folsom dev cycle had begun with the creation of a symbolic-ref to master, then further things interested in the thing called folsom could just follow that.

- Similar to debian, but opposite - in other cases one might want to pull "stable" - without specific knowledge of what the latest letter-based release might have been, and would like that to change whenever the latest stable thing is released.

A symbolic ref is a local construct, relevant to and resolved within the copy of the repository where it is created. To outside consumers it appears as a separate branch, so as long as the intent is to pull from and push to the particular repository where that symbolic ref lives this should work fine. However, if it's of interest to have those symbolic ref names available from other copies of repositories, they'll have to be created there manually unless you have low-level control sufficient to duplicate git symbolic-ref commands at that end (for example gitolite grew a feature recently enabling project owners to be able to add these: http://permalink.gmane.org/gmane.comp.version-control.git/182115 ). I couldn't find any positive confirmation that github has a similar feature, so further exploration there is in order.

Also worrisome, based my interpretation of this thread repointing things other than HEAD is probably an off-label use from upstream Git's perspective: http://git.661346.n2.nabble.com/What-s-the-definition-of-a-valid-Git-symbolic-reference-td6025154.html

I've thrown together a rudimentary proof-of-concept implementation of your symbolic-ref idea ( https://review.openstack.org/13928 ) and it seems to work as expected given the caveats above. I agree, however, with James E. Blair's concern that this will be either confusing or useless to downstream consumers since the reference is seen as a branch outside of the local copy on the Gerrit server. I'm also worried that zuul will act on changes it sees in these independently of the real branches they represent and, unless modified to ignore them explicitly by name, duplicate testing activities as a result.

In IRC he suggested constantly updating tags instead, so I've tested doing this with lightweight tags on my development Gerrit VM and it seems to fit the bill. A client can pull from a tag name instead of a branch name and will get the commit from the branch to which the tag refers, even if the tag has updated to point at a commit on a new branch since the last pull.

Given that there's at least one discussion proposed for ODS around reorganizing the branch structure and release branching process, further development on a solution should be postponed until we've got a clear picture of how things may change in that regard.

The lightweight tag solution seemed to be acceptable to all discussion participants at the summit (bug retitled accordingly), so I'm coding up a new proof-of-concept using a post-merge hook to track the tip of arbitrary branches specified in a YAML file kept in openstack-ci-puppet. Once I have it confirmed working on my test Gerrit instance, I'll check in a patch to add it on review-dev.openstack.org for more collaborative testing.

The https://review.openstack.org/14721 change implements a prototype using tags, as described above. Comments welcome.

Switching to wishlist and removing milestone. The change linked above can serve as a reference implementation if there's any interest in putting it into production. It's tested out and works as designed with gerrit and replication, but there's some question around who updates the configuration mapping names to branches and how that's integrated into the release process (both from a tooling and a human procedure perspective).