<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Apr 19, 2014 at 9:54 AM, James E. Blair <span dir="ltr"><<a href="mailto:jeblair@openstack.org" target="_blank">jeblair@openstack.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">Sean Dague <<a href="mailto:sean@dague.net">sean@dague.net</a>> writes:<br>
<br>
> On 04/18/2014 12:14 PM, Thierry Carrez wrote:<br>
>> Sean Dague wrote:<br>
>>> [...]<br>
>>> However, the specs process that nova, qa, and now neutron are using<br>
>>> seems quite useful to create a detailed set of guidelines that gather<br>
>>> agreement from the technical leadership of the project(s). It also would<br>
>>> let operators weigh in on this, and as they are one of the most affected<br>
>>> people by it, having their opinions would be great.<br>
>>><br>
>>> So I'd like to create some cross project specs repository, preferably<br>
>>> soon, so some initial work on this could be done prior to summit and can<br>
>>> be referenced when appropriate. One of the open questions is who has +A<br>
>>> on this? It could be the TC, as in some ways these are similar to<br>
>>> governance docs that affect all the projects. Honestly, to me who has<br>
>>> finally +A is less important, because I think this is about concensus.<br>
>>> However it does need to exist for us to even work on the concensus part.<br>
>>><br>
>>> So, question #1 - how would people feel about creating some cross<br>
>>> project specs repo RSN?<br>
>><br>
>> I'm not a complete fan of the idea. I mean, when does a given spec<br>
>> become cross-project ? Is it limited to blueprints that would affect<br>
>> EVERY project ? Is it accessible for blueprints that only affect 2<br>
>> projects ? Because there are a lot of those... and asking a TC+PTLs<br>
>> group to vet those sounds completely weird (the two involved PTLs should<br>
>> vet those).<br>
>><br>
>> That topic is basically why I wanted to have the cross-project workshop<br>
>> on "tracking incoming changes". I'm not sure separate repositories in<br>
>> each project are the solution. I can see a cross-project one quickly<br>
>> becoming abused, with the TC routinely overreaching into projects.<br>
>><br>
>> In an ideal world we would have a single repository, with multiple<br>
>> directories for each project and links to all affected projects, while<br>
>> still retaining per-project approvals and all. This is difficult to<br>
>> support in our repository / gerrit system...<br>
>><br>
>> Basically I'd prefer if we had that brainstorming first, before adding<br>
>> more repositories and more process.<br>
>><br>
>>> question #2 - what do we call it? os-specs, openstack-specs, tc-specs,<br>
>>> cross-project-specs?<br>
>>><br>
>>> question #3 - who is the core team?<br>
>>><br>
>>> I'd rather not wait until after summit, because I'd like some content<br>
>>> and back and forth before the operator days at summit, and doing that in<br>
>>> the wiki (where it currently is) doesn't really support that in the same<br>
>>> way.<br>
>><br>
>> I would still very much prefer if we waited. Maybe you can leverage<br>
>> other solutions to iterate on a doc in the mean time ? Etherpad maybe ?<br>
><br>
> Honestly, and etherpad is good for whiteboarding, but is really poor at<br>
> recording feedback past a couple of iterations.<br>
><br>
> I think barring an openstack-specs repo I'll probably start a github<br>
> repo and ask for pull requests / github issues there. I'd much rather do<br>
> this in gerrit, but I do really need a workflow where the document is<br>
> editable in "not a browser", and there can be detailed feedback given at<br>
> each point.<br>
<br>
</div></div>This would be a substantial change to the way we design and develop<br>
OpenStack and has had very little discussion at this point. Thierry has<br>
brought up some very good points and I think we should let the<br>
brainstorming and discussion happen before rushing into it.<br>
<br></blockquote><div><br></div><div>I'm with Jim and Thierry on this. So much more people work needs to happen before we start a common specs project. </div><div><br></div><div>I think we're also finding out tough it is to review words instead of code in git/gerrit. It's one of the findings of my docs survey, that git/gerrit is less liked than xml even. </div>
<div><br></div><div>That data doesn't mean we shouldn't do docs and specs in git/gerrit, it just means that there are probably other methods to get the discussion going and other workflows to consider for discussing design and decisions before going with an openstack-specs repo.</div>
<div><br></div><div>Anne</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
-Jim<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
OpenStack-TC mailing list<br>
<a href="mailto:OpenStack-TC@lists.openstack.org">OpenStack-TC@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc</a><br>
</div></div></blockquote></div><br></div></div>