Open Stack

On 6/2/15, 16:24, "Boris Pavlovic" <boris at pavlovic.me> wrote:

>Hi stackers, 
>
>
>Issue
>-------
>
>
>Projects are becoming bigger and bigger overtime.
>More and more people would like to contribute code and usually core
>reviewers
>team can't scale enough. It's very hard to find people that understand
>full project and have enough time to do code reviews. As a result team is
>very small under heavy load and many maintainers just get burned out.
>
>
>We have to solve this issue to move forward.
>
>
>
>
>Idea
>------
>
>
>Let's introduce subsystems cores.
>
>
>Really it's hard to find cores that understand whole project, but it's
>quite simple to find people that can maintain subsystems of project.
>
>
>
>
>How To
>-----------
>
>
>Gerrit is not so simple as it looks and it has really neat features ;)
>
>
>For example we can write own rules about who can put +2 and merge patch
>based on changes files.
>
>
>We can make special "subdirectory core" ACL group.
>People from such ACL group will be able to merge changes that touch only
>files from some specific subdirs.
>
>
>As a result with proper organization of directories in project we can
>scale up review process without losing quality.
>
>
>
>
>Thoughts?
>
>
>
>
>Best regards,
>Boris Pavlovic

I like this very much. I recall there was a session at the summit about
this that Thierry and Kyle led. If I recall correctly, the discussion
mentioned that it wasn't (at this point in time) possible to use gerrit
the way you describe it, but perhaps people were mistaken?

If we can do this exactly as you describe it, that would be awesome. If
there's a problem in limiting people to what files they can approve
changes for, then an alteration might be that those people get +2 but not
+W. This provides a signal to whomever has +W that the review is very much
ready to be merged. Does that sound fair?

Cheers,
Ian