Open Stack

On Sat, Apr 19, 2014 at 9:54 AM, James E. Blair <jeblair at openstack.org>wrote:

> 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.
>
>
I'm with Jim and Thierry on this. So much more people work needs to happen
before we start a common specs project.

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.

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.

Anne




> -Jim
>
> _______________________________________________
> OpenStack-TC mailing list
> OpenStack-TC at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-tc/attachments/20140419/7d407c4f/attachment.html>