Open Stack

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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160920/6fa5e399/attachment.html>