From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id D7D53138334 for ; Mon, 4 Feb 2019 19:00:50 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8A1B0E0CF9; Mon, 4 Feb 2019 19:00:49 +0000 (UTC) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 26850E0CF3 for ; Mon, 4 Feb 2019 19:00:48 +0000 (UTC) Received: by mail-lj1-x233.google.com with SMTP id u89-v6so842892lje.1 for ; Mon, 04 Feb 2019 11:00:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gentoo-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=0S8r/TjRIPmagHVTUKb8O1l8lQCLQCuss+nsH9mPscs=; b=WCk6QKVZeg/S2kRbKwSSgAds6RRnWByCZQR0F0vHnwrRGpaIxJIwDfQ9Njc7zcde+f pfMEtJWdLxejZUvSpylHxaGipr8M7uLp/ca5VBxMiAU9a5SmzT5YpU/J+DhBhAp1F4iG e+5CMyfpOVLNRSGgOX4pvwcGFdpoKNxDs8dIrTvonmhPZD2VwbOQlfkhnIwAxzPabmxB tVgv2UNYNZLke+pIphfcyoE31TCX/tgG9NhaPChqlHSFScUjofQefE6tVbmqqY1jzqru TmC5tjKV3IHHXolHlS4UJ3u/eTIM0eMamarCdOCB5qeqnfe7ymSpoDeSUDTY79v40Jfq qZgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=0S8r/TjRIPmagHVTUKb8O1l8lQCLQCuss+nsH9mPscs=; b=H4Uaf4EwinaA/uEhJjb9/wJr9QvJEexLzVlqWb2BaiUIWdBjXR+CAzoQ0D3eNTj9pZ 1O/Pf3e6AFmvMJp43eGCU6ORhkhc6W1XNIXW7jaRy1VQr7Ab8LvnLqHTKQ5vUSA7r+03 9e81fSvphe0uta4qeFESrVZkVsED+HcmMPk/PbbqbWydk061ftYzCTMq0E9wruEePanV XibE6qEZ2u/sRf5v/knj3M08uR4z7C3PgA3EV5OsbRw0SaSy+dLOmy0yR5FIAfxcl130 PHnk0romW7ubbBVLFvrCS6KIi/3eztRo50EdnObD0X56wGafQuYOOHzpJ0nvLjKP88Z+ EbPQ== X-Gm-Message-State: AHQUAuZjJIKSS6QbrSraoBj+Z+4Km4SQaFkUqWahHPxcEVxjneEr+b3K kLIKd6TVXiI5QxbT0N1rLi8T/CPFKk0yUYmFXSO7lH7GSVE= X-Google-Smtp-Source: AHgI3Ia0GE5a995lnaJZmRI4n0+bV7ncF3oIi4XZgl9MTqvyyp7DkR0hN1YowGLaMSVeGzbDkeF4aIDvuFks3EuxvhM= X-Received: by 2002:a2e:8e8e:: with SMTP id z14-v6mr537985ljk.84.1549306846646; Mon, 04 Feb 2019 11:00:46 -0800 (PST) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Project discussion list X-BeenThere: gentoo-project@lists.gentoo.org Reply-To: gentoo-project@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 References: <1549301931.893.35.camel@gentoo.org> In-Reply-To: <1549301931.893.35.camel@gentoo.org> From: Alec Warner Date: Mon, 4 Feb 2019 14:00:35 -0500 Message-ID: Subject: Re: [gentoo-project] [RFC] GURU v2, now with reviewed layer To: gentoo-project Content-Type: multipart/alternative; boundary="0000000000003e2b6a0581161c1b" X-Archives-Salt: 9913051d-6f6e-4e1f-a0f1-570f0e0bdc14 X-Archives-Hash: 2ede667338c9c96c8eada5017e460912 --0000000000003e2b6a0581161c1b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Feb 4, 2019 at 12:39 PM Micha=C5=82 G=C3=B3rny = 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 - 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=C5=82 G=C3=B3rny > --0000000000003e2b6a0581161c1b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Feb 4, 2019 at 12:39 PM Micha= =C5=82 G=C3=B3rny <mgorny@gentoo.or= g> wrote:
Hello,

After some initial discussion on the GURU user repository, I'd like to<= br> start bike... I mean, brainstorming v2 of the idea.=C2=A0 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.=C2=A0 Commits are merged fr= om
private to public after some kind of review.=C2=A0 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. Wha= t is it a branch of?

Like what I might expect is:<= /div>

repo - master # this is the public branch users us= e
repo - <literally thousands of other branches> These are = the in-progress or stale PRs.

When review is compl= ete, repo - somebranch is merged into repo - master.

Is this what you are proposing?

-A
=C2=A0

Now, reviews are normally done on commit ranges; by default, from
current state of public to current state of dev.=C2=A0 When such a range is=
reviewed, every commit belonging to it gains reputation.=C2=A0 When a range=
of commits gets reputation of 3, it is merged to public.

Reviews can be done by devs or privileges users.=C2=A0 Review by dev gives = 3
rep points, and by privileged user gives 1 rep point.=C2=A0 Therefore,
a commit is merged if it's either reviewed by dev or 3 privileged users= .


Users gain reviewing privilege also via reputation points.=C2=A0 If a commi= t
range including user's commit gets merged to master, user gets 1 rep point (independently of number of commits in the range).=C2=A0 When user ge= ts
5 rep points, he can start reviewing stuff.

Finally, besides positive approval we have option of flagging.=C2=A0 You ca= n
flag commits, e.g. for malicious code, vandalism, etc.=C2=A0 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.=C2=A0 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=C5=82 G=C3=B3rny
--0000000000003e2b6a0581161c1b--