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