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

[Ian Stakenvicius]

On 2019-02-05 11:41 a.m., Andrew Savchenko wrote:
> On Mon, 04 Feb 2019 18:38:51 +0100 Michał Górny 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.
>>
>> 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?
>
> How is it different from the sunrise overlay? We had very similar
> unreviewed/reviewed split model there. And you buried that project
> yourself ~2.5 years ago because it was stinking already.
>
> Furthermore such project will distort already thin resources from
> proxy maint and GH PR reviewers.
>
> So I see no practical point in resurrecting sunrise under another
> name and a slightly different policy. So please NO.
>
> Best regards,
> Andrew Savchenko
>

The primary difference I see between this new proposal and Sunrise is
that it isn't going to hinge on what ended up being a single gentoo
developer handling all of the publishing reviews, and there won't be a
review-before-initial-commit either.

I'm not sure if it will pull away from proxy-maint or GH PR's either,
but rather re-focus those two projects to allowing user-contributions
to existing gentoo-repo packages while this new project will be for
new packages.  If anything I think it may reduce the effort necessary
to keep up with those projects since new packages won't need to be
maintained there.*

Whether or not these differences are sufficient to empower us to make
this repo, I don't know -- Sunrise was started back when overlays were
few and not nearly as simple to create.  The idea of having everyone
commit to one place rather than each having their own could be better
in theory, but if users prefer to just run their own like they do now
then this project's going to be a bit of a waste...


* we could very well have an issue, just like we did with Sunrise,
where a dev moving the package to gentoo repo and 'taking over' from
the users that previously 'owned' it in GURU ends up causing some
conflict.  I don't recall if policy was ever sorted on that since iirc
we can have the same issue with proxy-maint too?