Open Stack

On 03/06/2014 03:15 AM, Thierry Carrez wrote:
> Steven Dake wrote:
>> My general take is workflow would fit in the Orchestration program, but
>> not be integrated into the heat repo specifically.  It would be a
>> different repo, managed by the same orchestration program just as we
>> have heat-cfntools and other repositories.  Figuring out how to handle
>> the who is the core team of people responsible for program's individual
>> repositories is the most difficult aspect of making such a merge.  For
>> example, I'd not desire a bunch of folks from Murano +2/+A heat specific
>> repos until they understood the code base in detail, or atleast the
>> broad architecture.   I think the same think applies in reverse from the
>> Murano perspective.  Ideally folks that are core on a specific program
>> would need to figure out how to learn how to broadly review each repo
>> (meaning the heat devs would have to come up to speed on murano and
>> murano devs would have to come up to speed on heat.  Learning a new code
>> base is a big commitment for an already overtaxed core team.
> Being in the same program means you share the same team and PTL, not
> necessarily that all projects under the program have the same core
> review team. So you could have different core reviewers for both
> (although I'd encourage the core for ones become core for the other,
> since it will facilitate behaving like a coherent team). You could also
> have a single core team with clear expectations set ("do not approve
> changes for code you're not familiar with").
>
This may be possible with jenkins permissions, but what I'd like to see 
is for a way for people familiar with each specific project to be 
graduated to core for that project.  (eg heat or workflow).  An implicit 
expectation do not approve doesn't  totally fit, because at some point, 
we may want to give those folks the ability to approve via a core 
nomination (because they have met the core requirements) for either heat 
or workflow.  WIthout a way of nominating for core for a specific 
project (within a specific program), the poor developer has no way to 
know when they have officially been recognized by the core team as an 
actual core member.

I agree folks in one program need to behave as a coherent team for the 
Orchestration program to be successful, which means a big commitment 
from the existing orchestration program core members (currently 
heat-core) to come up to speed on the example workflow code base and 
community (and vice-versa).

I'm a bit confused as well as to how a incubated project would be 
differentiated from a integrated project in one program.  This may have 
already been discussed by the TC.  For example, Red Hat doesn't 
officially support incubated projects, but we officially support (with 
our full sales/training/documentation/support/ plus a whole bunch of 
other Red Hat internalisms) Integrated projects.  OpenStack vendors need 
a way to let customers know (through an upstream page?) what a project 
in a specific program's status is so we can appropriately set 
expectations with the community and  customers.

Regards
-steve