On Sun, Dec 29, 2013 at 7:51 PM, John Dickinson <m...@not.mn> wrote: > > 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.
+1 > > 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 > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
