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 83C9C138334 for ; Mon, 4 Feb 2019 18:47:44 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 295E2E0D0B; Mon, 4 Feb 2019 18:47:24 +0000 (UTC) Received: from smtp.gentoo.org (smtp.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 D3379E0D0A for ; Mon, 4 Feb 2019 18:47:23 +0000 (UTC) Received: from pomiot (d202-252.icpnet.pl [109.173.202.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id DE608335C36; Mon, 4 Feb 2019 18:47:21 +0000 (UTC) Message-ID: <1549306037.893.48.camel@gentoo.org> Subject: Re: [gentoo-project] [RFC] GURU v2, now with reviewed layer From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= To: gentoo-project@lists.gentoo.org Date: Mon, 04 Feb 2019 19:47:17 +0100 In-Reply-To: <55ee18a6-45e9-0bf4-c3c1-e0917e073640@gmail.com> References: <1549301931.893.35.camel@gentoo.org> <55ee18a6-45e9-0bf4-c3c1-e0917e073640@gmail.com> Organization: Gentoo Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-wq1JlNm4G1raDrHu4/jH" X-Mailer: Evolution 3.26.6 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 X-Archives-Salt: 5f131e6d-ea24-43e7-9b73-75810eb4afa0 X-Archives-Hash: b4f270d00dcc156c56315bba02752a3c --=-wq1JlNm4G1raDrHu4/jH Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2019-02-04 at 20:14 +0200, Joonas Niilola wrote: > On 2/4/19 7:38 PM, Micha=C5=82 G=C3=B3rny 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= . >=20 > This could be 'exploited' with a group of friends. By exploited I mean= =20 > small inner circles forming, where people just approve their friends=20 > 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?= =20 > If no user wants to take a look, it will always require a review from a= =20 > dev, and judging how that goes even with current Github PRs, will it=20 > _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=20 > 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= =20 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 get= s > > 5 rep points, he can start reviewing stuff. >=20 > So this requires people to make commits to this overlay before being=20 > able to review there? Some system should exist, where for example your= =20 > commits to ::gentoo counts toward this. Otherwise this could encourage= =20 > 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? > >=20 >=20 > _If_ in this approach a dev is still needed for merging stuff in the=20 > end, couldn't this somehow be applied to how the current proxy-maint=20 > system works? >=20 >=20 > Is there a chance these ebuilds could end up in ::gentoo? _Could_ there= =20 > be some voting system for that (although I believe that kills the=20 > 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.=20 Testing stuff for ::gentoo is much more effort. > And as asked by someone in the previous thread, what's the plan of=20 > cleaning the overlay every now and then? (How?) Up to the users. >=20 > Who takes care of broken packages? >=20 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. --=20 Best regards, Micha=C5=82 G=C3=B3rny --=-wq1JlNm4G1raDrHu4/jH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQKTBAABCgB9FiEEXr8g+Zb7PCLMb8pAur8dX/jIEQoFAlxYiLZfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDVF QkYyMEY5OTZGQjNDMjJDQzZGQ0E0MEJBQkYxRDVGRjhDODExMEEACgkQur8dX/jI EQpc1A/9GSd98BaAQQ8SJiEc9T2VsrvgWbWhSLegKqV3sODw9WhCsttzZjvdUdeK H2mhEkYZVAyDUVgeDcLoDc37Cli3A7oadZrMzu5XBL6EPrwa7y63EXFDkQ/Gi+ml xj4B6K2P+G9Qx2XUk7UOuItx9jkMzRJPklGWNRT9lWS865GDp+obUn7qIhmjGgUb 3srYh6fawzce6Hg6zuemFJx2Utc2oqKzofNwMKWRcY6YQXr043aFsYU+vhvXdfJx Ydi9zsvYeS/iQiry2oqj01tTZ1KMmc5mIEKDsdQsFpp31iHSPiZZI8MB0ZmmeH/Y 2p8uqxf6lZaSEGoPNJWnjjMtxhFA+mOBouMwLk5pgPU+Nu5Rrygz7dIkkpRwWLSU ZBH1m8RLfzosG4wUl7Emh/MMYMZR69vSrtMwOl5krsF92cykAMduURqHqs1nOsSj gtY/I9+3Oto0LOtuVDJKg9V5GE72oXOw3yvt074T7jyCjmPK+VxiTp+5r7+0F1q+ lEYcxoZ70Cc7zP/dVhgBgbopeT8JpJZHtOTkRSBjmcc7GNNU6B2UEQcnWd0UETEY 6Hu4E52jmfxlep5mMvnZ0LA0dWx6ZXtYgcxTC28B6x8Lx73+pigFWU6wNvroA2Ns CBPDuFMKhVszwpH/83JKj2vOc9a9q/0q/QOLan9RPDh14E0Ub7Y= =jJPv -----END PGP SIGNATURE----- --=-wq1JlNm4G1raDrHu4/jH--