Open Stack

On 03/24/2014 02:19 PM, Monty Taylor wrote:
> 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.

OK, here it is for nova-specs: https://review.openstack.org/#/c/82564/

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

Yeah, some validation on the structure would be nice.

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

I think that would work for me.  I think we can do away with
juno/approved and juno/implemented and just have juno/.



-- 
Russell Bryant