Open Stack

Sean Dague <sean at dague.net> writes:

> 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.

This would be a substantial change to the way we design and develop
OpenStack and has had very little discussion at this point.  Thierry has
brought up some very good points and I think we should let the
brainstorming and discussion happen before rushing into it.

-Jim