Open Stack

On Sun, Dec 29, 2013 at 7:51 PM, John Dickinson <me at not.mn> wrote:
>
> 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.

+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 at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>