On 03/24/2014 10:07 AM, Russell Bryant wrote:
On 03/24/2014 12:34 PM, James E. Blair wrote:

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.


c) Some basic agreement on what information is encoded?

We've been working on a template in nova-specs here:


    eg: don't encode implementation status (it should be in launchpad)


    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

OpenStack-dev mailing list

Reply via email to