Open Stack

On Dec 29, 2013, at 2:05 PM, Michael Still <mikal at stillhq.com> wrote:

> On Mon, Dec 30, 2013 at 8:12 AM, John Dickinson <me at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131229/9489240a/attachment.pgp>