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 |