[openstack-dev] Spec repos for blueprint development and review
Monty Taylor
mordred at inaugust.com
Mon Mar 24 18:19:48 UTC 2014
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
>>
More information about the OpenStack-dev
mailing list