1 |
On April 6, 2019 12:37:36 AM GMT+09:00, "Michał Górny" <mgorny@g.o> wrote: |
2 |
>Hi, everyone. |
3 |
> |
4 |
>Some of you have read about my GURU idea already. For those who |
5 |
>haven't, a short description is included below. I'd like to start |
6 |
>a simpler demo for it, and I'm looking for people interested |
7 |
>in contributing. |
8 |
> |
9 |
> |
10 |
>GURU is meant to be something between Arch Linux's AUR and the past |
11 |
>Sunrise project -- an officially recognized repository made entirely |
12 |
>by users, with minimal supervision from Gentoo developers. |
13 |
|
14 |
|
15 |
Why making a new name? Betagarden or sunrise was not good enough? |
16 |
|
17 |
> |
18 |
>GURU would use two branches: a development branch where all interested |
19 |
>contributors will be allowed to commit freely, and a reviewed branch |
20 |
>where established members will push reviewed commits from |
21 |
>the development branch. This is very similar to Sunrise, except that |
22 |
>reviewing will not be limited to Gentoo developers. |
23 |
> |
24 |
>GURU would be only for new packages, or packages that are clearly |
25 |
>abandoned in ::gentoo. While the packages wouldn't land in ::gentoo, |
26 |
>having a single officially recognized place for them will help both |
27 |
>users and developers to find them, and to maintain a single version, |
28 |
>hopefully better than packages scattered all over private repositories. |
29 |
|
30 |
I'm worried that guru will delay inclusion of new packages in the Gentoo repository also in the case where just a pull request review would be enough for keeping a good quality overall. |
31 |
|
32 |
> |
33 |
>GURU would use three user classes: |
34 |
> |
35 |
>1. Contributors -- allowed to commit to development branch, directly |
36 |
>responsible for their own actions but advised to take care of whole dev |
37 |
>branch. |
38 |
> |
39 |
>2. Trusted contributors -- allowed to merge to master branch and to |
40 |
>accept new contributors. Responsible for quality of the master branch, |
41 |
>and for monitoring new contributors. |
42 |
> |
43 |
>3. Gentoo Developers -- allowed to appoint trusted contributors and |
44 |
>with |
45 |
>superpowers. Responsible for taking emergency actions. |
46 |
> |
47 |
>The basic idea is whenever a new user requests joining, one of |
48 |
>the trusted contributors (or developers) accepts him and starts |
49 |
>monitoring his activity (mostly to quickly detect malicious users). |
50 |
>When the user makes some recognizable good work, he becomes trusted |
51 |
>contributor (as approved by a Gentoo developer) and starts reviewing |
52 |
>stuff from dev branch and merging it to master branch. |
53 |
> |
54 |
>This is somewhat similar to Sunrise, except that instead of developers |
55 |
>reviewing stuff (which IMHO caused Sunrise's downfall), we let users do |
56 |
>that. Also, a major difference is that we allow inferior quality |
57 |
>ebuilds, and assume other contributors are free (and encouraged!) |
58 |
>to improve them. |
59 |
> |
60 |
> |
61 |
>I'm looking for all people interested in participating in all three |
62 |
>classes. That is: |
63 |
> |
64 |
>a. users interested in submitting their ebuilds to this repository, |
65 |
> |
66 |
>b. users interested in becoming trusted contributors and reviewing |
67 |
>stuff, |
68 |
> |
69 |
>c. developers interested in taking part of overseeing this. |
70 |
> |
71 |
>I'm willing to accept some of the recognized proxy-maint contributors |
72 |
>straight to category b. Though I should note that according to my |
73 |
>idea, |
74 |
>this is the category expected to have most work here. |
75 |
> |
76 |
>Gentoo Developers may expect some work especially at the beginning, |
77 |
>in order to bootstrap this. However, once we have strong trusted |
78 |
>contributor group the amount of work should decrease. |
79 |
> |
80 |
>Please note that the technical details haven't been decided yet. |
81 |
>The GURU repository will probably be hosted on Gentoo Infra (due to |
82 |
>need |
83 |
>for git hooks). I'm going to try pushing a bit more for our own GitLab |
84 |
>instance but if that fails, gitolite would probably have to be good |
85 |
>enough. In that case, I will be taking care of adding people on behalf |
86 |
>of others. |
87 |
|
88 |
Gitlab instance? We have a Gentoo official Gitlab instance? |
89 |
|
90 |
-- |
91 |
Sent from my Android device with K-9 Mail. Please excuse my brevity. |