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 49C77138334 for ; Tue, 5 Feb 2019 16:41:42 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 0728DE09F0; Tue, 5 Feb 2019 16:41:41 +0000 (UTC) Received: from smtp.gentoo.org (woodpecker.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (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 AE457E09EF for ; Tue, 5 Feb 2019 16:41:40 +0000 (UTC) Received: from localhost (unknown [91.246.99.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: bircoph) by smtp.gentoo.org (Postfix) with ESMTPSA id BF18D335DBD for ; Tue, 5 Feb 2019 16:41:37 +0000 (UTC) Date: Tue, 5 Feb 2019 19:41:33 +0300 From: Andrew Savchenko To: gentoo-project@lists.gentoo.org Subject: Re: [gentoo-project] [RFC] GURU v2, now with reviewed layer Message-Id: <20190205194133.2e78aee8fc4825c2d9439eba@gentoo.org> In-Reply-To: <1549301931.893.35.camel@gentoo.org> References: <1549301931.893.35.camel@gentoo.org> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; i686-pc-linux-gnu) 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 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA512"; boundary="Signature=_Tue__5_Feb_2019_19_41_33_+0300_g2hyjMQGfP.wbhrF" X-Archives-Salt: c212b7f5-39a0-4223-97ec-71d057bc7e56 X-Archives-Hash: 092f5264c4309f9e5dd7b63c4a04dea0 --Signature=_Tue__5_Feb_2019_19_41_33_+0300_g2hyjMQGfP.wbhrF Content-Type: text/plain; charset=UTF-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, 04 Feb 2019 18:38:51 +0100 Micha=C5=82 G=C3=B3rny wrote: > Hello, >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. > =20 >=20 > 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. >=20 > 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.=20 > Furthermore, devs can issue bans to users responsible for the bad stuff. >=20 > That's my idea, roughly. The main points are: >=20 > - stuff is reviewed before publishing to users, >=20 > - people are encouraged to review stuff, as previous unreviewed commits > are going to block their own, >=20 > - initially reviews are done by devs but as users gain reputation, they > start being able to review ebuilds committed by others, >=20 > - flagging gives extra protection against mistakes. >=20 > 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 --Signature=_Tue__5_Feb_2019_19_41_33_+0300_g2hyjMQGfP.wbhrF Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE63ZIHsdeM+1XgNer9lNaM7oe5I0FAlxZvL0ACgkQ9lNaM7oe 5I1YGBAAowgWdf4QDgu5jDi6fBDcbstDONbX7jn0d2HLj1zlEQVsA2cbIIuWgQzV t3g5Ws9jB1SPEcGKFHFQOP9Tm2U//dkhNkLgokfkJWuRRBltSTXf5Q6mlUbxC/Zu IMJzspDjbxDPdWP+JLwL1PzJ9aN27b/VmO33BcAXHyni5C5f3Iq3rmd6BVuyh87q J0EdlJscXSBRSsphLhKV464IYTWuoN34N1m6VNRdXOBXTmNkjGGkJlwke3ZTqwr/ Z9603GlpOAupztqDrmGbTnFFzAnHtqNJO6PTWCU+H7d7Qzm2NT5PK2N6OF22EwXn VvBRocdPfJaCIHfmWhd0wsB6Icb86DLXki2gvltXLUin3CpvoVcLwXjS8SqTw8qE bE4xc//ispkC5qlOAIknYS236MD7IN1ebkib3aiORcdqotJ209tMQ+4RPufxEHav K2JjUKeUtD0N6M4MIg9AJnetXKmGdbtHXZPmdF4LVHp4iAdGuO/36xHduzl++dPS DBYQwLX9E4WSxypOvqajTmTw+cpP7++TeLWNg4TQSB+247zS9oHLRSelZXZi4lzk a+nR5HFkggsnUztqHqdPss3bZPI5Iec12oafoXts9nvYNcYNds8ACZ8WmbasOHvf CH9/IA5pOc6KRKYILf0dY6c/nGYey+f6xR3zgDGVwdqU80aCs5A= =6dBd -----END PGP SIGNATURE----- --Signature=_Tue__5_Feb_2019_19_41_33_+0300_g2hyjMQGfP.wbhrF--