<div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Mar 24, 2014 at 3:17 PM, Matthew Treinish <span dir="ltr"><<a href="mailto:mtreinish@kortar.org" target="_blank">mtreinish@kortar.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">On Mon, Mar 24, 2014 at 02:32:35PM -0400, Russell Bryant wrote:<br>

> On 03/24/2014 02:19 PM, Monty Taylor wrote:<br>
> > On 03/24/2014 10:07 AM, Russell Bryant wrote:<br>
> >> On 03/24/2014 12:34 PM, James E. Blair wrote:<br>
> >>> Hi,<br>
> >>><br>
> >>> So recently we started this experiment with the compute and qa programs<br>
> >>> to try using Gerrit to review blueprints.  Launchpad is deficient in<br>
> >>> this area, and while we hope Storyboard will deal with it much better,<br>
> >>> but it's not ready yet.<br>
> >><br>
> >> This seems to be a point of confusion.  My view is that Storyboard isn't<br>
> >> intended to implement what gerrit provides.  Given that, it seems like<br>
> >> we'd still be using this whether the tracker is launchpad or storyboard.<br>
> >><br>
> >>> As a development organization, OpenStack scales by adopting common tools<br>
> >>> and processes, and true to form, we now have a lot of other projects<br>
> >>> that would like to join the "experiment".  At some point that stops<br>
> >>> being an experiment and becomes practice.<br>
> >>><br>
> >>> However, at this very early point, we haven't settled on answers to some<br>
> >>> really basic questions about how this process should work.  Before we<br>
> >>> extend it to more projects, I think we need to establish a modicum of<br>
> >>> commonality that helps us integrate it with our tooling at scale, and<br>
> >>> just as importantly, helps new contributors and people who are working<br>
> >>> on multiple projects have a better experience.<br>
> >>><br>
> >>> I'd like to hold off on creating any new specs repos until we have at<br>
> >>> least the following questions answered:<br>
> >><br>
> >> Sounds good to me.<br>
> >><br>
> >>> a) Should the specs repos be sphinx documents?<br>
> >><br>
> >> Probably.  I see that the qa-specs repo has this up for review.  I'd<br>
> >> like to look at applying this to nova-specs and see how it affects the<br>
> >> workflow we've had in mind so far.<br>
> >><br>
> >>> b) Should the follow the Project Testing Interface[1]?<br>
> >><br>
> >> As its relevant, sure.<br>
> ><br>
> > I think the main one here, as is in mtrenish's patch, is to make sure<br>
> > "tox -evenv python setup.py build_sphinx" works.<br>
><br>
> OK, here it is for nova-specs: <a href="https://review.openstack.org/#/c/82564/" target="_blank">https://review.openstack.org/#/c/82564/</a><br>
><br>
<br>
</div></div>The matching qa-specs one that Monty mentioned before is here:<br>
<br>
<a href="https://review.openstack.org/#/c/82531/" target="_blank">https://review.openstack.org/#/c/82531/</a><br>
<br>
I also took the initiative and took what Russell and I did for the qa-specs and<br>
nova-specs repos and started a cookiecutter template for making new specs repos<br>
and put it on github:<br>
<br>
<a href="https://github.com/mtreinish/specs-cookiecutter" target="_blank">https://github.com/mtreinish/specs-cookiecutter</a><br>
<br>
This way once everything is sorted out from this thread we can have a common<br>
base for adding new specs repos for other projects.<br>
<div class=""><br>
> > Additionally, if we want to do code-style analysis, I'd suggest putting<br>
> > it into tox -epep8. I know that soudns LUDICROUS right now, but I really<br>
> > want to rename that to tox -elint or something  -because it's long since<br>
> > stopped being just pep8 anywhere.<br>
> ><br>
> > Or?<br>
><br>
> Yeah, some validation on the structure would be nice.<br>
><br>
<br>
</div>Sean has a review up for a basic validation tool here:<br>
<a href="https://review.openstack.org/#/c/81347/" target="_blank">https://review.openstack.org/#/c/81347/</a><br>
<br>
Like Jim mentioned in the review it probably makes the most sense to put that in<br>
common place instead of in tree so that all the specs repos can use it easily.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Jim's suggest to make that an installable tool seems like the right approach to me.</div>
<br></div><div><div class="gmail_default" style="font-size:small">On a related note, it took most of this release cycle to work out all of the steps involved in creating a new code repository, set up gating, etc. because they hadn't all been written down in one place before. We have a *lot* of institutional knowledge wrapped up in the heads of a few heavy contributors on the infra and QA teams, and sussing it out took quite a few false-starts and IRC conversations. During those conversations, some of us talked about creating a manual for project maintainers (rather than just developers) with this sort of information. It would be really really nice if this new part of our process was documented formally as part of that guide. If someone starts it with the spec repository instructions, I will add information based on <a href="https://wiki.openstack.org/wiki/Oslo/CreatingANewLibrary">https://wiki.openstack.org/wiki/Oslo/CreatingANewLibrary</a> to fill it out for code repositories. (Jim Blair had a name for what he wanted the manual to be called, but I don't remember off the top of my head.)</div>
</div><div><br></div><div><div class="gmail_default" style="font-size:small">Doug</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div class=""><br>
<br>
> >>> c) Some basic agreement on what information is encoded?<br>
> >><br>
> >> We've been working on a template in nova-specs here:<br>
> >><br>
> >> <a href="http://git.openstack.org/cgit/openstack/nova-specs/tree/template.rst" target="_blank">http://git.openstack.org/cgit/openstack/nova-specs/tree/template.rst</a><br>
> >><br>
> >>>     eg: don't encode implementation status (it should be in launchpad)<br>
> >><br>
> >> Agreed<br>
> >><br>
> >>>     do encode branches (as directories? as ...?)<br>
> >><br>
> >> IMO, yes.  The reason is that I think approval of a spec should be<br>
> >> limited to a given release.  If it slips, it should be re-reviewed to<br>
> >> make sure it still makes sense given whatever developments have<br>
> >> occurred.  That's why we have a juno/ directory in nova-specs.<br>
> ><br>
> > My biggest concern about the directories is where it relates to<br>
> > workflow. Essentially, I think we should not _move_ them - because there<br>
> > will be blueprints in either launchpad or storyboard with a link to the<br>
> > URL of the thing. If we later move the spec because it got re-targetted,<br>
> > we'll have a bunch of broken links.<br>
> ><br>
> > Instead, if we copy the spec to the new location (say, kestral) when<br>
> > it's time - OR - we move the spec but leave behind a placeholder doc in<br>
> > the old location that says "retargetted to kestral" - then I think we're<br>
> > in a good place.<br>
> ><br>
> > (this is why I think the implemented and approved dirs are bad)<br>
> ><br>
> > If we can do that, then I can totally buy the argument about having<br>
> > $release dirs.<br>
><br>
> I think that would work for me.  I think we can do away with<br>
> juno/approved and juno/implemented and just have juno/.<br>
><br>
><br>
<br>
</div>-Matt Treinish<br>
<div class=""><div class="h5"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>