Gentoo Archives: gentoo-project

From: "Michał Górny" <mgorny@g.o>
To: gentoo-project <gentoo-project@l.g.o>
Subject: [gentoo-project] [RFC] New project: GURU [Gentoo User Repository, Unreviewed]
Date: Sun, 03 Feb 2019 19:29:13
Message-Id: 1549222129.929.25.camel@gentoo.org
1 Hello,
2
3 I'd like to collect feedback on starting a new project focused
4 on providing a platform to users work on ebuilds without the explicit
5 need for developer intervention.
6
7
8 Why?
9 ----
10 The current contribution platforms seem inadequate to the needs of our
11 users. In particular:
12
13 - Submissions via Bugzilla etc. are inconvenient for anyone to use,
14 and basically rely on some developer taking them up and transferring
15 to ::gentoo.
16
17 - Proxy-maint requires a lot of effort for both contributors
18 and developers. We're undermanned for quite some time and can't handle
19 all the contributions timely. Plus, not every contributor wants to
20 become package maintainer.
21
22 - User repositories are cheap to create but cause ebuilds to be
23 scattered all over the place. In the end, they're inconvenient to
24 users, and adding them and cleaning up unmaintained repos afterwards
25 costs me a lot of effort.
26
27 While all of those venues have their use case, we seem to lack something
28 akin Arch Linux's AUR. What I'm specifically aiming for here is
29 a single place where users can maintain (or not) packages themselves
30 without unnecessary developer intervention. Something like Sunrise,
31 except without reviews.
32
33
34 What do I propose?
35 ------------------
36 GURU would be an official repository maintained entirely by Gentoo
37 users. I'm thinking of Wiki-like workflow where anyone is allowed to
38 add new ebuilds or modify existing ebuilds, and users are expected to
39 keep order. Gentoo developers would be allowed to contribute
40 on the same terms as users; official developer intervention would be
41 only used to resolve conflicts and other kinds of trouble.
42
43
44 Open issues
45 -----------
46 1. Should the access be open or explicitly granted? If the latter, how
47 should we determine whether to grant access for a particular
48 contributor?
49
50 2. Where should it be hosted? Gentoo Infra is unsuitable for open
51 access, as we would have to add all keys manually. GitHub, GitLab, etc.
52 are all options.
53
54 3. How far should Gentoo policies apply? I think we should enforce
55 sign-off per copyright policy but let users resolve issues beyond that.
56
57 4. Should it be purely for new packages, or should forking Gentoo
58 packages be allowed? I'm thinking allowing forks for unmaintained
59 or severely outdated Gentoo packages makes sense.
60
61 5. And most importantly, what should the last 'U' stand for? My initial
62 idea was 'Unreviewed' but I'm open to better-sounding ideas.
63
64
65 Foreseen Q&A
66 ------------
67
68 * Will it replace proxy-maint?
69
70 No, proxy-maint will continue working as-is. I expect some contributors
71 may switch over, and some will simply submit ebuilds both ways.
72 Ideally, GURU may serve as initial ebuild improvement/proofreading
73 exercise before moving to ::gentoo.
74
75 * Why not revive Sunrise instead?
76
77 The problem with Sunrise is that it needs active developers. Given that
78 it died pretty much because people lost interest, I don't think trying
79 to artificially revive it is going to help. Instead, I'd like to try
80 something new and see how it works.
81
82 * Who will be allowed to commit?
83
84 The idea is that everybody will be allowed to commit. I'm not planning
85 to enforce strong maintainer boundaries like in Gentoo. However,
86 in the end I expect the people actually working on GURU to decide
87 and establish best practices themselves.
88
89 * What if somebody submits malware?
90
91 This risk is inevitable. Hopefully, the Wiki-like workflow will
92 eventually create some kind of mutual review of new commits, and users
93 will look out for suspicious ebuilds. Users will be able to revert them
94 themselves, and developers will block reported accounts if necessary.
95
96 That said, please remember that no other way of submitting ebuilds is
97 free of this risk. Believe me, we don't really review the code of every
98 submitted package, and if somebody wrote a program with malicious
99 functionality and wanted to package it, it will probably be accepted.
100
101 * What if somebody misbehaves?
102
103 I think we will reserve the right to ban contributors who repeatedly
104 misbehave (e.g. remove packages, commit offensive stuff, etc.).
105
106
107 ---
108 What do you think?
109
110 --
111 Best regards,
112 Michał Górny

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies