Open Stack

On 04/19/2014 06:28 AM, Sean Dague wrote:
> On 04/18/2014 12:14 PM, Thierry Carrez wrote:
>> Sean Dague wrote:
>>> [...]
>>> However, the specs process that nova, qa, and now neutron are using
>>> seems quite useful to create a detailed set of guidelines that gather
>>> agreement from the technical leadership of the project(s). It also would
>>> let operators weigh in on this, and as they are one of the most affected
>>> people by it, having their opinions would be great.
>>>
>>> So I'd like to create some cross project specs repository, preferably
>>> soon, so some initial work on this could be done prior to summit and can
>>> be referenced when appropriate. One of the open questions is who has +A
>>> on this? It could be the TC, as in some ways these are similar to
>>> governance docs that affect all the projects. Honestly, to me who has
>>> finally +A is less important, because I think this is about concensus.
>>> However it does need to exist for us to even work on the concensus part.
>>>
>>> So, question #1 - how would people feel about creating some cross
>>> project specs repo RSN?
>>
>> I'm not a complete fan of the idea. I mean, when does a given spec
>> become cross-project ? Is it limited to blueprints that would affect
>> EVERY project ? Is it accessible for blueprints that only affect 2
>> projects ? Because there are a lot of those... and asking a TC+PTLs
>> group to vet those sounds completely weird (the two involved PTLs should
>> vet those).
>>
>> That topic is basically why I wanted to have the cross-project workshop
>> on "tracking incoming changes". I'm not sure separate repositories in
>> each project are the solution. I can see a cross-project one quickly
>> becoming abused, with the TC routinely overreaching into projects.
>>
>> In an ideal world we would have a single repository, with multiple
>> directories for each project and links to all affected projects, while
>> still retaining per-project approvals and all. This is difficult to
>> support in our repository / gerrit system...
>>
>> Basically I'd prefer if we had that brainstorming first, before adding
>> more repositories and more process.
>>
>>> question #2 - what do we call it? os-specs, openstack-specs, tc-specs,
>>> cross-project-specs?
>>>
>>> question #3 - who is the core team?
>>>
>>> I'd rather not wait until after summit, because I'd like some content
>>> and back and forth before the operator days at summit, and doing that in
>>> the wiki (where it currently is) doesn't really support that in the same
>>> way.
>>
>> I would still very much prefer if we waited. Maybe you can leverage
>> other solutions to iterate on a doc in the mean time ? Etherpad maybe ?
> 
> Honestly, and etherpad is good for whiteboarding, but is really poor at
> recording feedback past a couple of iterations.
> 
> I think barring an openstack-specs repo I'll probably start a github
> repo and ask for pull requests / github issues there. I'd much rather do
> this in gerrit, but I do really need a workflow where the document is
> editable in "not a browser", and there can be detailed feedback given at
> each point.

Apparently I screwed up my mail client settings so I'm now missing Anne
and Jim's responses, so I'll just reply to my own.

I definitely see the concern on setting future policy here, what the
approval mechanics are. For those reasons I do think it make sense to
hold off on a global repository, we can do that discussion at summit.

I'll try to figure out some interim location so there can be some
progress prior to summit. Given that Nova has already expressed a lot of
interest in this (mikal actually commented on that when I had done the
clean-logs bp, which is just the elimination of errors), that might be a
good place to do the specs for the first round. I'll circle there.

Partially related, it definitely feels like we've got pro and anti
gerrit camps. I'd be interested in exploring why that is. As a community
we've got a wide variety of experiences here, and it would be
interesting to figure out if there are common patterns of usage that are
putting people in either camp. Those would be either patterns or anti
patterns that we could highlight to make everyone's experience better.

	-Sean

-- 
Sean Dague
Samsung Research America
sean at dague.net / sean.dague at samsung.com
http://dague.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-tc/attachments/20140421/583cd6f5/attachment.pgp>