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.


OpenStack-dev mailing list

Reply via email to