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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
