Open Stack

On 03/24/2014 10:07 AM, Russell Bryant wrote:
> On 03/24/2014 12:34 PM, James E. Blair wrote:
>> Hi,
>>
>> So recently we started this experiment with the compute and qa programs
>> to try using Gerrit to review blueprints.  Launchpad is deficient in
>> this area, and while we hope Storyboard will deal with it much better,
>> but it's not ready yet.
>
> This seems to be a point of confusion.  My view is that Storyboard isn't
> intended to implement what gerrit provides.  Given that, it seems like
> we'd still be using this whether the tracker is launchpad or storyboard.
>
>> As a development organization, OpenStack scales by adopting common tools
>> and processes, and true to form, we now have a lot of other projects
>> that would like to join the "experiment".  At some point that stops
>> being an experiment and becomes practice.
>>
>> However, at this very early point, we haven't settled on answers to some
>> really basic questions about how this process should work.  Before we
>> extend it to more projects, I think we need to establish a modicum of
>> commonality that helps us integrate it with our tooling at scale, and
>> just as importantly, helps new contributors and people who are working
>> on multiple projects have a better experience.
>>
>> I'd like to hold off on creating any new specs repos until we have at
>> least the following questions answered:
>
> Sounds good to me.
>
>> a) Should the specs repos be sphinx documents?
>
> Probably.  I see that the qa-specs repo has this up for review.  I'd
> like to look at applying this to nova-specs and see how it affects the
> workflow we've had in mind so far.
>
>> b) Should the follow the Project Testing Interface[1]?
>
> As its relevant, sure.

I think the main one here, as is in mtrenish's patch, is to make sure 
"tox -evenv python setup.py build_sphinx" works.

Additionally, if we want to do code-style analysis, I'd suggest putting 
it into tox -epep8. I know that soudns LUDICROUS right now, but I really 
want to rename that to tox -elint or something  -because it's long since 
stopped being just pep8 anywhere.

Or?

>> c) Some basic agreement on what information is encoded?
>
> We've been working on a template in nova-specs here:
>
> http://git.openstack.org/cgit/openstack/nova-specs/tree/template.rst
>
>>     eg: don't encode implementation status (it should be in launchpad)
>
> Agreed
>
>>     do encode branches (as directories? as ...?)
>
> IMO, yes.  The reason is that I think approval of a spec should be
> limited to a given release.  If it slips, it should be re-reviewed to
> make sure it still makes sense given whatever developments have
> occurred.  That's why we have a juno/ directory in nova-specs.

My biggest concern about the directories is where it relates to 
workflow. Essentially, I think we should not _move_ them - because there 
will be blueprints in either launchpad or storyboard with a link to the 
URL of the thing. If we later move the spec because it got re-targetted, 
we'll have a bunch of broken links.

Instead, if we copy the spec to the new location (say, kestral) when 
it's time - OR - we move the spec but leave behind a placeholder doc in 
the old location that says "retargetted to kestral" - then I think we're 
in a good place.

(this is why I think the implemented and approved dirs are bad)

If we can do that, then I can totally buy the argument about having 
$release dirs.

>> d) Workflow process -- what are the steps to create a new spec and make
>>     sure it also exists and is tracked correctly in launchpad?
>
> For nova-specs, the first piece of info in the template is a blueprint URL.
>
> On the launchpad side, nothing will be allowed to be targeted to a
> milestone with an approved spec attached to it.
>
>> [1] https://wiki.openstack.org/wiki/ProjectTestingInterface
>
>