Open Stack

On 29/12/13 19:24 -0800, John Dickinson wrote:
>
>On Dec 29, 2013, at 5:24 PM, Michael Still <mikal at stillhq.com> wrote:
>
>> On Mon, Dec 30, 2013 at 11:51 AM, John Dickinson <me at not.mn> wrote:
>>> On Dec 29, 2013, at 2:05 PM, Michael Still <mikal at 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.
>


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.

Cheers,
FF

-- 
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131230/c596519a/attachment.pgp>