Re: [openstack-dev] [All] tagged commit messages
On Mon, 2013-12-30 at 11:04 +0100, Flavio Percoco wrote: I like the idea of having custom tags. I'm a bit concerned about the implications this might have with cross-project collaborations. I mean, people contributing to more projects will have to be aware of the many possible differences in this area. That being said, I can think of some cases where we this could be useful for other projects. However, I'd encourage to keep common tags documented somewhere, perhaps this common tags shouldn't be part of the `Tags:` 'field', which you already mentioned above. If I may be allowed a tangent—should a mechanism external to the commit message be allowed for attaching a tag to a review? Consider the recent ext3/ext4 change: a reviewer could browse that and say, This should have a DeploymentImpact tag. With the tags as so far described in this thread, that has to be something added by the submitter (or a new version of the patch uploaded by a reviewer). Can we create a mechanism that would allow a reviewer to attach such a tag without having to modify any part of the review? Can the mechanism allow such an attachment even if the review has already been merged? Just something to think about :) -- Kevin L. Mitchell kevin.mitch...@rackspace.com Rackspace ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [All] tagged commit messages
On 30/12/13 13:44 -0600, Kevin L. Mitchell wrote: On Mon, 2013-12-30 at 11:04 +0100, Flavio Percoco wrote: I like the idea of having custom tags. I'm a bit concerned about the implications this might have with cross-project collaborations. I mean, people contributing to more projects will have to be aware of the many possible differences in this area. That being said, I can think of some cases where we this could be useful for other projects. However, I'd encourage to keep common tags documented somewhere, perhaps this common tags shouldn't be part of the `Tags:` 'field', which you already mentioned above. If I may be allowed a tangent—should a mechanism external to the commit message be allowed for attaching a tag to a review? Consider the recent ext3/ext4 change: a reviewer could browse that and say, This should have a DeploymentImpact tag. With the tags as so far described in this thread, that has to be something added by the submitter (or a new version of the patch uploaded by a reviewer). Can we create a mechanism that would allow a reviewer to attach such a tag without having to modify any part of the review? Can the mechanism allow such an attachment even if the review has already been merged? https://www.kernel.org/pub/software/scm/git/docs/git-notes.html Just something to think about :) -- Kevin L. Mitchell kevin.mitch...@rackspace.com Rackspace ___ 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
Re: [openstack-dev] [All] tagged commit messages
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
Re: [openstack-dev] [All] tagged commit messages
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
Re: [openstack-dev] [All] tagged commit messages
On Dec 29, 2013, at 5:24 PM, Michael Still mi...@stillhq.com wrote: On Mon, Dec 30, 2013 at 11:51 AM, John Dickinson m...@not.mn wrote: On Dec 29, 2013, at 2:05 PM, Michael Still mi...@stillhq.com wrote: [snip] 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. [snip] Super aggressive trimming, because I want to dig into this one bit some more... I feel like anything that requires pro-active action from the target audience will fail. For example, in nova we've gone through long cycles with experimental features where we've asked deployers to turn on new features in labs and report problems before we turn it on by default. They of course don't. So... I feel there is value in a curated list of tags, even if we allow additional tags (a bit like launchpad). In fact, the idea of a DeployImpact tag for example really works for me. I'm very tempted to implement that one in notify_impact now. Yup, I understand and agree with where you are coming from. Let's discuss DeployImpact as an example. First, I like the idea of some set of curated tags (and you'll see why at the end of this email). Let's have a way that we can tag a commit as having a DeployImpact. Ok, what does that mean? In some manner of speaking, _every_ commit has a deployment impact. So maybe just things that affect upgrades? Is that changes? New features? Breaking changes only (sidebar: why would these sort of changes ever get merged anyway? moving on...)? My point is that a curated list of tags ends up being fairly generic to the point of not being too useful. Ok, we figured out the above questions (ie when to use DeployImpact and when to not use it). Now I'm a deployer and packager (actually not hypothetical, since my employer is both for Swift), so what do I do? Do I have to sign up for some sort of thing? Does this mean a gerrit code review cycle to some -infra project? That would be a pretty high barrier for getting access to that info. Or maybe the change-merged action for a DeployImpact tag simply sends an email to a new DeployImpact mailing list or puts a new row in a DB somewhere that is shown on some page ever time I load it? In that case, I've still got to sign up for a new mailing list (and remember to not filter it and get everyone in my company who does deployments to check it) or remember to check a particular webpage before I do a deploy. Maybe I'm thinking about this wrong way. Maybe the intended audience is the rest of the OpenStack dev community. In that case, sure, now I have a way to find DeployImpact commits. That's nice, but what does that get me? I already see all the patches in my email and on my gerrit dashboard. Being able to filter the commits is nice, but constraining that to an approved list of tags seems heavy-handed. So while I like the idea of a curated list of tags, in general, I don't think they lessen the burden for the intended audience (the intended audience being people not in the dev/contributor community but rather those deploying and using the code). That's why a tool that can parse git commit messages seems simple and flexible enough to meet the needs of deployers (eg run `git log commit | tagged-search deployimpact` before packaging) without requiring the overhead of managing a curated tag list via code repo changes (as DocImpact is today). All that being said, I'll poke some holes in my own idea. The problem with my idea is letting deployers know what tags they should actually search for. In this case, there probably should be some curated list of high-level tags that should be used across all OpenStack projects. In other words, if I use deploy-change on my patch and you use DeploymentImpact, then what does a packager/deployer search for? There should be some set of tags with guidelines for their usage on the wiki. I'd propose starting with ConfigDefaultChanged, DependencyChanged, and NewFeature. --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
