Gentoo Archives: gentoo-project

From: Alec Warner <antarus@g.o>
To: gentoo-project <gentoo-project@l.g.o>
Subject: Re: [gentoo-project] [RFC] GURU v2, now with reviewed layer
Date: Mon, 04 Feb 2019 19:00:50
Message-Id: CAAr7Pr9+9SGGnY1Yf5mR8_7rF5wVn0F+u667E_w3pY+oH+kZiw@mail.gmail.com
On Mon, Feb 4, 2019 at 12:39 PM Michał Górny <mgorny@g.o> wrote:

> Hello, > > After some initial discussion on the GURU user repository, I'd like to > start bike... I mean, brainstorming v2 of the idea. This time it's more > like Sunrise but with some automation in mind. > > Let's go with two layers like Sunrise -- one private working branch, > and another public that's exposed to users. Commits are merged from > private to public after some kind of review. I suppose to avoid > depgraph misshots etc. we'd want to move commits incrementally, i.e. > public is only doing fast-forward merges from dev. >
I'm looking for more information on the private branch. What is it a branch of? Like what I might expect is: repo - master # this is the public branch users use repo - <literally thousands of other branches> These are the in-progress or stale PRs. When review is complete, repo - somebranch is merged into repo - master. Is this what you are proposing? -A
> > Now, reviews are normally done on commit ranges; by default, from > current state of public to current state of dev. When such a range is > reviewed, every commit belonging to it gains reputation. When a range > of commits gets reputation of 3, it is merged to public. > > Reviews can be done by devs or privileges users. Review by dev gives 3 > rep points, and by privileged user gives 1 rep point. Therefore, > a commit is merged if it's either reviewed by dev or 3 privileged users. > > > Users gain reviewing privilege also via reputation points. If a commit > range including user's commit gets merged to master, user gets 1 rep > point (independently of number of commits in the range). When user gets > 5 rep points, he can start reviewing stuff. > > Finally, besides positive approval we have option of flagging. You can > flag commits, e.g. for malicious code, vandalism, etc. If a commit is > flagged, merging it is blocked until a dev resolves the flag. > Furthermore, devs can issue bans to users responsible for the bad stuff. > > That's my idea, roughly. The main points are: > > - stuff is reviewed before publishing to users, > > - people are encouraged to review stuff, as previous unreviewed commits > are going to block their own, > > - initially reviews are done by devs but as users gain reputation, they > start being able to review ebuilds committed by others, > > - flagging gives extra protection against mistakes. > > Your updated thoughts? > > -- > Best regards, > Michał Górny >