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
