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

Attachment: 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

Reply via email to