Open Stack

On 03/24/2014 01:07 PM, 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.
> 
>> 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

We are working on a template in qa-specs, though intentionally kind of
loose. I think some of the items like problem, solution, and
implementors map well. And we'll probably copy those. A lot of the rest
of it doesn't so much.

Especially if we think about the differences between a spec to implement
a tempest change, one to implement a grenade change, and one to do
something in infrastructure like multi node testing. As qa-specs is
intentionally not tempest-specs, it's for the qa program.

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

So this is an area that I think there are differences for between
programs. Because I don't actually think automatic reset makes sense for
the QA program. Because unlike a server program that is very strongly
release bounded, QA is only loosely release bounded. We don't do a
feature freeze in the same way as the server projects.

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

https://github.com/openstack/qa-specs - is where we started with the
process, it's pretty explicit. Our template is still evolving, though
we're going to go intentionally pretty loose on it at this point to
figure out what's working and what isn't in the template.

	-Sean

-- 
Sean Dague
Samsung Research America
sean at dague.net / sean.dague at samsung.com
http://dague.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140324/5881efee/attachment.pgp>