[openstack-dev] [all][infra][tc][ptl] Scaling up code review process (subdir cores)
boris at pavlovic.me
Wed Jun 3 11:56:57 UTC 2015
Reverting patches is unacceptable for Rally project.
This means that we merged bug and this is epic fail of PTL of project.
Let's take a look from other side, Ihar would you share with me
your password of your email?
You can believe me I won't do anything wrong with it.
And "yes" I don't want to trust anybody this is huge amount of work to PTL.
PTL in such case is bottleneck because he need to check that all 100500+
subcores are reviewing pieces that they can review and passing +2 only on
patches that they can actually merge.
Let's just automate this stuff.
Like we have automated CI for testing.
On Wed, Jun 3, 2015 at 2:28 PM, Ihar Hrachyshka <ihrachys at redhat.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> On 06/03/2015 08:29 AM, Boris Pavlovic wrote:
> > Guys,
> > I will try to summarize all questions and reply on them:
> > *- Why not splitting repo/plugins?*
> > I don't want to make "architectural" decisions based on "social" or
> > "not enough good tool for review" issues.
> > If we take a look at OpenStack that was splited many times:
> > Glance, Cinder, ... we will see that there is a log of code
> > duplication that can't be removed even after two or even more years
> > of oslo effort. As well it produce such issues like syncing
> > requirements, requirements in such large bash script like devstack,
> > there is not std installator, it's quite hard to manage and test
> > it and so on..
> > That's why I don't think that splitting repo is good
> > "architecture" decision - it makes simple things complicated...
> > *- Why not just trust people*
> > People get tired and make mistakes (very often).
> I wouldn't say they make mistakes *too* often. And if there is a
> mistake, we always have an option to git-revert and talk to the guy
> about it. I believe no one in the neutron team merges random crap, and
> I would expect the same from other openstack teams.
> It's also quite natural that people who do more reviews extend their
> field of expertise. Do we really want to chase PTLs to introduce a
> change into turing-complete-acl-description each time we feel someone
> is now ready to start reviewing code from yet another submodule?
> Or consider a case when a patch touches most, if not all submodules,
> but applies some very trivial changes, like a new graduated oslo
> library being consumed, or python3 adoption changes. Do you want to
> wait for a super-core with enough ACL permissions for all those
> submodules touched to approve it? I would go the opposite direction,
> allowing a single core to merge such a trivial patch, without waiting
> for the second one to waste his time reviewing it.
> Core reviewers are not those who are able to put +2 on any patch, but
> those who are able to understand where *not* to put it. I would better
> allow people themselves to decide where they are capable and where
> their expertise ends, and free PTLs from micro-managing the cats.
> So in essence: mistakes are cheap; reputation works; people are
> responsible enough; and more ACL fences are evil.
> > That's why we have blocking CI system that checks patches,
> Those checks are easy to automate. Trust is not easily formalized though
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
> -----END PGP SIGNATURE-----
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev