Gentoo Archives: gentoo-project

From: "Michał Górny" <mgorny@g.o>
To: gentoo-project@l.g.o
Subject: Re: [gentoo-project] [RFC] GURU v2, now with reviewed layer
Date: Mon, 04 Feb 2019 18:47:44
In Reply to: Re: [gentoo-project] [RFC] GURU v2, now with reviewed layer by Joonas Niilola
On Mon, 2019-02-04 at 20:14 +0200, Joonas Niilola wrote:
> On 2/4/19 7:38 PM, Michał Górny wrote: > > 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. > > This could be 'exploited' with a group of friends. By exploited I mean > small inner circles forming, where people just approve their friends > commits without looking at them.
You can never prevent exploitation. However, you can make it harder and I think this model (possibly with n>3) works towards that goal. If we notice people doing bad stuff, we can always ban them and regaining the privileges makes things non-trivial enough.
> What about ebuilds not many people have knowledge of? Say, java stuff? > If no user wants to take a look, it will always require a review from a > dev, and judging how that goes even with current Github PRs, will it > _ever_ get approved here?
The main purpose of the review is to block malicious stuff from going unnoticed, not provide ::gentoo-level of thorough code reviews. I think most of the people will be able to spot suspicious stuff, independently of language or build system. If it is hidden well enough, then I doubt trained Java people would notice it either.
> What would motivate a developer to review these ebuilds, if there's > still separate proxy-maint stuff to work on?
Ideally, the system would work without developer intervention. Once enough users gain review privileges, the system becomes self-sustainable and developer intervention is limited to reacting on flagged commits.
> 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. > > So this requires people to make commits to this overlay before being > able to review there? Some system should exist, where for example your > commits to ::gentoo counts toward this. Otherwise this could encourage > people to make meaningless commits just to satisfy the counter.
1) You get only one point for the whole series of commits, so making extra commits for the sake of it doesn't grant you anything. 2) I suppose it'd make sense to make it possible for reviewers to decide if they grant committers reputation points. So if you made meaningless commits, the reviewer would just uncheck a box next to your name and you wouldn't gain anything.
> > Your updated thoughts? > > > > _If_ in this approach a dev is still needed for merging stuff in the > end, couldn't this somehow be applied to how the current proxy-maint > system works? > > > Is there a chance these ebuilds could end up in ::gentoo? _Could_ there > be some voting system for that (although I believe that kills the > incentive of ever adding this overlay as a user)?
Voting won't help proxy-maint. Active contributors pre-reviewing stuff and helping get it improved does but it's still a lot of effort from developers. The point is, as long as it's not ::gentoo, we can live with ebuilds that fail to build due to silly mistakes or otherwise need improvement. Testing stuff for ::gentoo is much more effort.
> And as asked by someone in the previous thread, what's the plan of > cleaning the overlay every now and then? (How?)
Up to the users.
> > Who takes care of broken packages? >
Up to you. You either fix it, or if it's broken beyond repair, you remove it. Possibly plus revdeps. The whole point of it being user repository is that users are supposed to do the work. Just imagine you're a Gentoo developer and you need to make sure your repository is neat. -- Best regards, Michał Górny


File name MIME type
signature.asc application/pgp-signature