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

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2031 bytes --]

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?

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

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

[Kristian Fiskerstrand]

On 2/4/19 6:38 PM, Michał Górny wrote:
> Your updated thoughts?

Doesn't change the underlying facts, something like this can be done
using existing mechanisms outside of Gentoo, and Gentoo should focus on
the main ebuild repository.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2084 bytes --]

On Mon, 2019-02-04 at 18:38 +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.
> 

Hm, I should've given an example here.  Let's say that commits are named
for successive latin letters, i.e. A B C D...

Public branch is at commit C.  Dev branch is at commit F.

User 1 clicks big 'I WANNA REVIEW STUFF' button.  He's given a diff
C..F.  If he approves this diff, commits C..F get +1 point.

Now dev branch is at commit H.  User 2 clicks the big button.  He's
given a diff C..H.  If he approves it, commits C..H get +1 point.  This
means C..F has 2 points already.

Now dev branch is at commit I.  User 3 clicks the big button.  He's
given a diff C..I.  If he approves it, commits C..I get +1 point.  This
means C..F is merged to public, F..H has 2 points and I has 1 point.

Dev branch is at J.  User 4 clicks the big button.  Now he's given
the diff F..J.  If he approves, F..J gets +1.  F..H is merged, I has 2
points, J has 1 point.

Next review would be based on H..master, etc.

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

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

[Joonas Niilola]

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. I think after 3 approvals it should be 
pushed to be on top of some(/all) dev's to-be-merged list. But then 
again, would this system be any faster than current proxy-maint 
workflow, where other proxied maintainers already review and approve PRs?


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?


What would motivate a developer to review these ebuilds, if there's 
still separate proxy-maint stuff to work on?


>   
>
> 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.


> 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)?


Still gotta say, this should prove to be a nice learning ground, and 
maybe a good place to host popular not-in-tree packages. Or with 
semi-dead projects where users are still trying to contribute (like MATE).

Although I believe everyone's motivation is to get them in ::gentoo in 
the end.


And as asked by someone in the previous thread, what's the plan of 
cleaning the overlay every now and then? (How?)

Who takes care of broken packages?

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

[Rich Freeman]

On Mon, Feb 4, 2019 at 1:14 PM Joonas Niilola <juippis@gmail.com> wrote:
>
> 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.

It sounds like you still need to get the 3 points from already-vetted
users to get credit towards having a reputation of your own in the
proposal.  So, a group of users with no reputation could not confer
reputation to each other.

Otherwise you could have innocent/ignorant users approving each
other's work and gaining reputation without knowing what they're
doing.  Alternatively you could have a malicious user use sock puppets
to gain reputation trivially.

Of course a malicious user could still gain reputation by making
genuine contributions.  They would just need to do this with three
accounts to have the equivalent of developer access.  Of course, by
that argument somebody can also maliciously become a developer.  I
don't think the system has to be bulletproof - it just has to be
enough of a barrier so that you don't get a ton of low-effort attacks.

My alternate proposal of having users maintian their own trust bits
for contributors has the same weakness.  Somebody doing enough good
work can start slipping in malware.  Short of actually verifying
identity documents and so on we aren't going to solve that problem.

-- 
Rich

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 3952 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

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

[Alec Warner]

[-- Attachment #1: Type: text/plain, Size: 2576 bytes --]

On Mon, Feb 4, 2019 at 12:39 PM Michał Górny <mgorny@gentoo.org> 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
>

[-- Attachment #2: Type: text/html, Size: 3333 bytes --]

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1525 bytes --]

On Mon, 2019-02-04 at 14:00 -0500, Alec Warner wrote:
> On Mon, Feb 4, 2019 at 12:39 PM Michał Górny <mgorny@gentoo.org> 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?
> 

No.  As I said, I'm proposing a Sunrise-layout layout.

dev -- branch which contributors use to work on their ebuilds.

reviewed -- branch which users use.

When commits are reviewed, fast-forward merges are done from dev
to reviewed.

Attempting to automatically merge multiple independent branches will
inevitably result in unpredictable final state.

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

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

[Alec Warner]

[-- Attachment #1: Type: text/plain, Size: 1922 bytes --]

On Mon, Feb 4, 2019 at 2:04 PM Michał Górny <mgorny@gentoo.org> wrote:

> On Mon, 2019-02-04 at 14:00 -0500, Alec Warner wrote:
> > On Mon, Feb 4, 2019 at 12:39 PM Michał Górny <mgorny@gentoo.org> 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?
> >
>
> No.  As I said, I'm proposing a Sunrise-layout layout.
>
> dev -- branch which contributors use to work on their ebuilds.
>
> reviewed -- branch which users use.
>
> When commits are reviewed, fast-forward merges are done from dev
> to reviewed.
>

I think my thoughts were around where CI would go. Does CI happen
post-commit on reviewed? Or does it matter for the PR that is the FF merge
between dev and reviewed, and the FF merge is not committed until CI passes?

-A


>
> Attempting to automatically merge multiple independent branches will
> inevitably result in unpredictable final state.
>
> --
> Best regards,
> Michał Górny
>

[-- Attachment #2: Type: text/html, Size: 2852 bytes --]

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2048 bytes --]

On Mon, 2019-02-04 at 14:52 -0500, Alec Warner wrote:
> On Mon, Feb 4, 2019 at 2:04 PM Michał Górny <mgorny@gentoo.org> wrote:
> 
> > On Mon, 2019-02-04 at 14:00 -0500, Alec Warner wrote:
> > > On Mon, Feb 4, 2019 at 12:39 PM Michał Górny <mgorny@gentoo.org> 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?
> > > 
> > 
> > No.  As I said, I'm proposing a Sunrise-layout layout.
> > 
> > dev -- branch which contributors use to work on their ebuilds.
> > 
> > reviewed -- branch which users use.
> > 
> > When commits are reviewed, fast-forward merges are done from dev
> > to reviewed.
> > 
> 
> I think my thoughts were around where CI would go. Does CI happen
> post-commit on reviewed? Or does it matter for the PR that is the FF merge
> between dev and reviewed, and the FF merge is not committed until CI passes?
> 

I suppose we enable CI on both branches, and block merges if CI on dev
is red.

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

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

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 2596 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

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

[Ian Stakenvicius]

[-- Attachment #1.1: Type: text/plain, Size: 4081 bytes --]

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?



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

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

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 2840 bytes --]

On Tue, 5 Feb 2019 13:06:28 -0500 Ian Stakenvicius wrote:
> On 2019-02-05 11:41 a.m., Andrew Savchenko wrote:
[...]
> > 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...

Frankly, that's what I'm expecting based on sunrise experience.
 
> * 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?

No, we don't have similar problem with proxy-maint. Proxied
maintainers are considered on par with regular developers when we
are talking about touching other people stuff: that is, a developer
can't touch package owned by proxied maintainer if he's not his
proxy or if there is no prior agreement with proxied maintainer, or
if a timeout was not reached for proxied maintainer reply.

Another great difference is that both GH PR's and PM are improving
the official Gentoo repository while proposed GURU repo will be a
separate project.

And since it is a separate project, any developer (or proxy
maintainer) will be free to add whatever they want from GURU to the
main Gentoo tree.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]