1 |
Hello everyone, |
2 |
|
3 |
this is my Council manifesto in form of a detailed answer to all |
4 |
questions that were currently raised. Michał, if I missed a question, |
5 |
please tell me :-) |
6 |
|
7 |
|
8 |
|
9 |
On Sun, Jul 1, 2018, at 14:37 CDT, Michał Górny <mgorny@g.o> wrote: |
10 |
|
11 |
> - How do you feel about Gentoo's use of GitHub? Do you support Gentoo |
12 |
> providing resources for our users on GitHub? Or are you opposed to |
13 |
> using GitHub at all? |
14 |
|
15 |
I think that reaching out to a wider audience of contributors via Github |
16 |
is a good idea. Github is a good platform for that because it simply has |
17 |
by far the largest number of users that could potentially readily |
18 |
contribute. |
19 |
|
20 |
In my opinion we should take some additional precautions, though: |
21 |
Because github is a closed-source and for-profit third party we must |
22 |
ensure that |
23 |
|
24 |
- github is not used for bug tracking (i.e., close all repository issue |
25 |
trackers) |
26 |
|
27 |
- we should encourage projects to use our own gitolite infrastructure |
28 |
for overlays (mirrored to github.com/gentoo-mirrors) |
29 |
|
30 |
The current incident - as unfortunate as it is - has not much to do with |
31 |
Github. (Meaning, if we would have used Gitlab, or another platform then |
32 |
that one would have been compromised.) Some lessons learned: |
33 |
|
34 |
- We should educate on rsync/tree validation (currently working on that with |
35 |
fellow developers) |
36 |
|
37 |
- Do not use passwords for authentication if possible (i.e. use ssh |
38 |
pubkeys, or gpg auth/signatures for authentication). If passwords are |
39 |
unavoidable, we should enforce two-factor authentication (at minimum |
40 |
for admins). |
41 |
|
42 |
|
43 |
|
44 |
On Fri, Jun 29, 2018, at 00:15 CDT, Eray Aslan <eras@g.o> wrote: |
45 |
|
46 |
> 1/ What do you think of closing gentoo-dev ML to the general public? |
47 |
|
48 |
We restricted posting on the gentoo-dev ML to whitelisted users for the |
49 |
time being to ensure that the mailing list communication channel is |
50 |
remains unobstructed (similar to, e.g., +v/+o in #gentoo-dev). I think |
51 |
that this step was necessary to stop individuals from abusing the |
52 |
mailing list for their personal agenda and to stop persistent trolls. |
53 |
|
54 |
We are currently working on reviving a moderator team for the gentoo-dev |
55 |
ML. With a moderator team in place (that ensures on-topic discussion |
56 |
with hopefully minimal intervention) the mailing list can be reopened |
57 |
again for posting for the general public. Hopefully in a timely manner. |
58 |
|
59 |
|
60 |
|
61 |
> 2/ Where do you think Gentoo stands in the Linux ecosystem? Who do you |
62 |
> think are its users? |
63 |
|
64 |
Gentoo has a fairly niche standing in the Linux ecosystem as being one |
65 |
of the only entirely source-based Linux distributions. As such a number |
66 |
of our user base consists of people that need that level of |
67 |
customization - examples range from scientific software ecosystems to |
68 |
using Gentoo as a meta distribution for an in-house distribution in |
69 |
larger data centers. Or users that like to have that level of |
70 |
control. All in all, I would say we have a pretty fine and knowledgeable |
71 |
user base. |
72 |
|
73 |
|
74 |
|
75 |
On Wed, Jun 27, 2018, at 03:25 CDT, Michał Górny <mgorny@g.o> wrote: |
76 |
|
77 |
> 1. Do you believe that Council members should respect the requests of |
78 |
> the developer community even if they disagree with them? Or should |
79 |
> Council members decide based on their own judgment of arguments |
80 |
> presented? |
81 |
> |
82 |
> Example: there's a heated debate, and the majority of respondents |
83 |
> request that X is implemented. However, after reading all the arguments |
84 |
> you don't think that X is a good idea but you haven't managed to |
85 |
> convince others. Would you vote for X (as your electorate demands) |
86 |
> or against it (as you believe is better for the distro)? |
87 |
|
88 |
The council is merely an elected body of developers to make the process |
89 |
of finding formal decisions more streamlined. The Gentoo project itself |
90 |
is entirely defined and shaped by its members/developers. I think that |
91 |
the current form of annual council elections creates a bit of a |
92 |
disconnect between the council and the developer base. Because of that I |
93 |
support the introduction of a "general resolution" voting mechanism |
94 |
for more basic democratic control [1,2]. |
95 |
|
96 |
|
97 |
|
98 |
> 2. Do you believe that the Council should proactively research the state |
99 |
> of affairs and make decisions whenever they believe the direction |
100 |
> of the distribution needs to be adjusted? Or should it be passive |
101 |
> and avoid involvement unless developers explicitly request Council's |
102 |
> intervention? |
103 |
|
104 |
I think that the overall "state of affairs" and decision making |
105 |
regarding the project as a whole should lie within the developer body as |
106 |
a whole. As such, the Council should be careful with such decisions. If |
107 |
necessary, there is always the possibility to initiate an "all dev" |
108 |
vote [1]. |
109 |
|
110 |
|
111 |
|
112 |
> 3. Do you believe the developer community should hold the power |
113 |
> to veto or dissolve the Council at any point? Provided there's a global |
114 |
> developer vote agreeing on that. |
115 |
|
116 |
Yes. |
117 |
|
118 |
|
119 |
|
120 |
> What do council-nominees think about the current lack of manpower in Gentoo as a |
121 |
> whole, and how do you propose to confront this situation, with facts? |
122 |
|
123 |
> In the same line that previous question, what global decisions do you consider |
124 |
> necessary in order to solve the manpower issue? |
125 |
|
126 |
The "current lack of manpower" situation is a never ending story, isn't |
127 |
it? We have maintained a more or less constant number of active |
128 |
developers over the years :-) |
129 |
|
130 |
- I have seen quite a few of our active github contributors becoming |
131 |
developrs in relatively short time. So streamlining the contribution |
132 |
process (pull request instead of bug report + attaching patches) has |
133 |
played out nicely, I would say. |
134 |
|
135 |
- The situation with maintainer-needed and maintainer-wanted improved |
136 |
quite a bit as well. Overall I think we are slowly catching up on |
137 |
portage tree cleaning (EAPI 0 - 4 removal, etc). |
138 |
|
139 |
- I think that due to the fact that we are a rolling release |
140 |
distribution we lack "visibility" a bit due to the absence of regular |
141 |
release announcements. Thus, maintaining special occasion live-cd |
142 |
releases and similar events is a good thing. |
143 |
|
144 |
- Finally, reducing the need for manpower is also an important point, I |
145 |
should mention here. For example, we have significantly smaller arch |
146 |
teams nowadays but the more streamlined and more automated |
147 |
stabilization process balances that. |
148 |
|
149 |
On the other hand, I wish sometimes that fellow developers would be |
150 |
a bit more conscious when it comes to introducing maintenance |
151 |
burden (USE=libressl is such an example...) |
152 |
|
153 |
|
154 |
|
155 |
> Finally, and this is just a personal opinion, right now I see many devs trying |
156 |
> to pull Gentoo to different sides, but what I can't see is a set of common |
157 |
> beliefs that join us all in the same vision of what Gentoo should be or do in |
158 |
> the near future... how could you address this issue? |
159 |
|
160 |
Being a meta distribution that provides solutions for a very diverse set |
161 |
of needs I don't exactly see a problem in diverse agendas. I think the |
162 |
current process of GLEPs, PMS, RFCs and council decisions provide a good |
163 |
mechanism to find a common ground and solutions that helps everybody. |
164 |
|
165 |
Given the very diverse background of personal agends, it is actually an |
166 |
amazing display of self-organization that we all stick together to make |
167 |
Gentoo a better platform for all of us. I think that, the unfortunate |
168 |
noisy discussion we have at times, hide this little fact a bit and |
169 |
people tend to forget how peaceful coexistence looks like :-) |
170 |
|
171 |
|
172 |
|
173 |
On Tue, Jun 26, 2018, at 02:12 CDT, Michał Górny <mgorny@g.o> wrote: |
174 |
|
175 |
> And I'd like to ask the inevitable question: what do you think should be |
176 |
> the roles of Gentoo Council and Trustees appropriately? |
177 |
|
178 |
[3] As already stated publicy otherwise: |
179 |
|
180 |
""" |
181 |
We request that the Board of Trustees of the Gentoo Foundation and the |
182 |
Gentoo Council affirm Gentoo's metastructure GLEP 39 as the governing |
183 |
principle of the Gentoo Linux developer community. In particular, both |
184 |
acknowledge the intended (non-exclusive) split between |
185 |
- the Gentoo Developer community, currently lead by the Gentoo Council, |
186 |
which is responsible for the developer community, its user base and |
187 |
all technical development decisions, |
188 |
- and the Gentoo Foundation, whose role is to hold Gentoo's assets |
189 |
(such as trademarks and server infrastructure) and support the |
190 |
developer and user community. Although the Board of Trustees |
191 |
exercises its own independent judgment on every decision, it |
192 |
generally carries out requests from the community. |
193 |
""" |
194 |
|
195 |
|
196 |
|
197 |
Best, |
198 |
Matthias |
199 |
|
200 |
|
201 |
|
202 |
[1] https://archives.gentoo.org/gentoo-project/message/973be0a662b3cc74aa118a1128dcac9e |
203 |
[2] https://archives.gentoo.org/gentoo-project/message/dffe725b064bf240834d5fe4ae78a83d |
204 |
[3] https://archives.gentoo.org/gentoo-nfp/message/a7c1b4e8df8690c8829d8854f767856f |