On Dec 29, 2013, at 2:05 PM, Michael Still <mi...@stillhq.com> wrote:
> On Mon, Dec 30, 2013 at 8:12 AM, John Dickinson <m...@not.mn> wrote: >> I've seen several disconnected messages about tags in commit messages. I've >> seen >> what is possible with the DocImpact tag, and I'd like to have some more >> flexible tagging >> things too. I'd like to use tags for things like keeping track of config >> defaults changing, >> specific ongoing feature work, and tracking changes come release time. > > I suspect I'm the last person to have touched this code, and I think > expanding tags is a good idea. However, I'm not sure if its the best > mechanism possible -- if a reviewer requires a tag to be added or > changed, it currently requires a git review round trip for the > developer or their proxy. Is that too onerous if tags become much more > common? > > I definitely think some more formal way of tracking that a given patch > needs to be covered by the release notes is a good idea. > > There are currently two hooks that I can see in our gerrit config: > > - patchset-created > - change-merged > > I suspect some tags should be "executed" at patchset-merged? For > example a change to flag defaults might cause a notification to be > sent to interested operators? > > Perhaps step one is to work out what tags we think are useful and at > what time they should execute? I think this is exactly what I don't want. I don't want a set of predefined tags. We've got that today with DocImpact and SecurityImpact. What I want, for very practical examples in Swift, are tags for config changes so deployers can notice, tags for things with upgrade procedures, tags for dependency changes, tags for "this is a new feature", all in addition to the existing DocImpact and SecurityImpact tag. In other words, just like impacted teams get alerted for changes that impact docs, I want "patches that impact Swift proxy-server configs" to be tracked (and bin scripts, and dependencies, and ring semantics, and etc). I think you're absolutely right that some things should happen at patchset-created time and others at change-merged time. Like you I'm also concerned that adding a new tag may be too heavyweight if it requires a code push/review/gate cycle. Here's an alternative: 1) Define a very lightweight rule for tagging commits (eg: one line, starts with "tags:", is comma-separated) 2) Write an external script to parse the git logs and look for tags. It normalizes tags (eg lowercase+remove spaces), and allow simple searches (eg "show all commits that are tagged 'configchange'"). That wouldn't require repo changes to add a tag, gives contributors massive flexibility in tagging, doesn't add new dependencies to code repos, and is lightweight enough to be flexible over time. Hmmm...actually I like this idea. I may throw together a simple script to do this and propose using it for Swift. Thanks Michael! --John > > Michael > > -- > Rackspace Australia > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
