Re: [gentoo-project] [RFC] GURU v2, now with reviewed layer

[Michał Górny]

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