Open Stack

On Mon, Apr 21, 2014 at 6:02 AM, Sean Dague <sean at dague.net> wrote:

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

Great idea. I think people love reviews until they go through so many
rounds they don't feel productive or that they'll miss deadlines. That's
what I'm hearing in docs feedback (which is also very release-centric, we
get it at release time, you all get it at milestone time).

I also wonder if the gerrit dislike is actually CLA dislike at the root, so
let's explore that in Mark's cross-project CLA discussion.

Anne


>
>         -Sean
>
> --
> Sean Dague
> Samsung Research America
> sean at dague.net / sean.dague at samsung.com
> http://dague.net
>
>
> _______________________________________________
> 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/20140421/0b37471f/attachment.html>