Le 20/09/2016 13:07, Matthew Booth a écrit :
* +A is reserved for cores.
* A subsystem maintainer's domain need not be defined by the directory
tree: subteams are a good initial model.
* A maintainer should only +2 code in their own domain in good faith,
enforced socially, not technically.
* Subsystem maintainer is expected to request specific additional +2s
for patches touching hot areas, eg rpc, db, api.
* Hot areas are also good candidate domains for subsystem maintainers.
* Hot area review need not cover the whole patch if it's not
required: I am +2 on the DB change in this patch.
This model means that code with +2 from a maintainer only requires a
single +2 from a core.
We could implement this incrementally by defining a couple of pilot
subsystem maintainer domains.
tl;dr: The retrospective effort should cover that concern and discuss
about it, but I also want to share a few thoughts meanwhile.
So, I was formerly (2 years ago) proposing about that. In case you find
some of my thoughts in the ML, please know that I have another opinion now.
What changed during the last 2 years for me ? I worked on some important
blueprints for my domain, and then I had to implement some changes that
were not only for my domain. For example, for a blueprint, I needed to
add some RPC version, I had to modify a Nova object and I had to add
some DB migration.
When I implemented the above, I saw that I wasn't exactly knowing how it
was working. I needed to go out of my domain, look at other changes and
review them, ping other people in IRC that were experts in their own
domains, and try to implement with a lot of new PSes.
Then, I thought about my previous opinion. What if I was reviewing my
own changes ? I mean, the changes were about my domain, but I wasn't
able to correctly make sure the patches were okay for Nova. For example,
I could have made a terrible modification for adding a new RPC version
that could have been terrible for my domain service if it was merged by
that time. I wasn't really understanding why Nova objects were useful,
why it was important to use them not only for the compute service, but
for other APIs.
Then, I understood how I was IMHO wrong. Instead of trying to have my
changes merged, I should rather try to understand why I was failing to
correctly implement by the first PS.
That's why I'm far more in favor of the subteam model. Instead of trying
to reduce the number of core people approving changes, we should rather
create some ecosystem where people with mutual interest can help
themselves by reviewing their respective changes, and then tell to the
world that they think the patch is ready. That doesn't mean that they
thought about all the possible problems, so that's why we still need 2
formal +2s, but at least the knowledge is shared between all subteam
members (ideally if they respectively review between themselves) so that
the expertise grows far more than just the domain boundaries, and for a
bunch of people, not a single person.
Anyway, like Sean said, that concern is totally worth being discussed
thanks to the retrospective effort, and I'm sure it will be.
-Sylvain
Matt
--
Matthew Booth
Red Hat Engineering, Virtualisation Team
Phone: +442070094448 (UK)
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
