[openstack-dev] Spec repos for blueprint development and review
rbryant at redhat.com
Mon Mar 24 18:32:35 UTC 2014
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:
>>> 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?
>> 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.
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:
>>> 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.
I think that would work for me. I think we can do away with
juno/approved and juno/implemented and just have juno/.
More information about the OpenStack-dev