Gentoo Archives: gentoo-user

From: hasufell <hasufell@g.o>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] Gentoo's future directtion ?
Date: Sun, 23 Nov 2014 23:45:51
Message-Id: 547271A2.1060003@gentoo.org
In Reply to: Re: [gentoo-user] Gentoo's future directtion ? by Rich Freeman
1 On 11/24/2014 12:24 AM, Rich Freeman wrote:
2 >>
3 >> So regrouping is not as easy as you make it sound. Totally not. I don't
4 >> like ruby eclasses and their virtuals. What can I do? Fix them? No, I
5 >> cannot. Stop saying I can fix everything I please. That is incorrect and
6 >> our model makes it even more complicated, because all that stuff is part
7 >> of the tree.
8 >
9 > What would you do under your proposal? You'd start a new repository
10 > with your own set of ruby packages.
11 >
12 > What would you do under the current state? You'd fork the ruby eclass
13 > and all the ruby packages.
14 >
15 > Yes, you're allowed to do that. The thing that keeps you from doing
16 > it is the same thing that will keep you from starting a new ruby
17 > repository - it is a lot of work.
18 >
19
20 No, I am not doing it because I think it is utterly wrong to introduce
21 two competing concepts in one repository, _especially_ on eclass level.
22 That's bad for QA, bad for consistency and bad for the user.
23
24 It's a completely different thing for a package like udev and totally
25 unrelated... those are forked UPSTREAM.
26
27
28 >>
29 >> You say I can fix the nethack bug? Well, I talked with various people on
30 >> how to do that, the basic idea was to stop using the games eclass. That
31 >> is NOT possible unless you suggest we break QA standards and cause major
32 >> inconsistencies in our tree. (the other possible fix just slipped my
33 >> radar and will probably happen soon)
34 >
35 > Just stop using the eclass. Cite the QA standards that this would
36 > violate. The council ruled a month ago that games are free to use the
37 > eclass or not as they wish.
38 >
39 > As long as you actually commit to maintaining the Nethack package, you
40 > can do this.
41 >
42
43 As above: I think it's wrong.
44
45 >>
46 >> Again: this is a culture thing and we have to make ourselves some
47 >> policies on how this can work well.
48 >
49 > The policies ALREADY allow you to do all this stuff. What policy
50 > specifically needs to be changed?
51 >
52 >> * abandon CVS finally
53 >
54 > Already underway.
55 >
56 >> * have proper contribution channels (NOT bugzilla)
57 >
58 > By all means create it. Lots of us are interested in this.
59 >
60 >> * kickban major assholes from the community, no matter how efficient
61 >> they are
62 >
63 > Proposals welcome. Hint, things will go much better if you volunteer
64 > to do the work the assholes are doing... It isn't like we aren't all
65 > tired of this stuff, but if we go booting half the devs then the
66 > distro will basically die.
67 >
68 >> * kickban people from IRC channels that make fun of your first ebuild
69 >> (that's my first experience with gentoo btw... that guy is now a gentoo
70 >> dev as well)
71 >
72 > Flag down a mod when this happens. If you can't find any, then
73 > volunteer to be a mod. IRC is a realtime medium, so it is very
74 > manpower-intensive.
75 >
76 >> * have a _working_ comrel project
77 >
78 > Again, proposals welcome. Half the problem with comrel is that
79 > everybody gets so sick of all the second-guessing that they give up.
80 > People would rather work on stuff that is interesting and not deal
81 > with infighting. When we tried to institute the proctors we managed
82 > to drive them away in a day.
83 >
84 > Everybody wants a working comrel, which generally means they want to
85 > get rid of all the people they don't like, and not have any
86 > restrictions on their own behavior.
87 >
88 >> * fix project internal communication... it's unbelievably bad
89 >
90 > What is wrong with it, specifically?
91 >
92 >> * stop the way we are recruiting, it's utterly tedious
93 >
94 > Well, then don't participate in it. By all means offer improvements.
95 >
96
97 I have offered one right now, including
98 * changes to the project structure (shrinking the amount of devs,
99 concentrating on the core, base-system, toolchain, PM)
100 * changes to the culture (REVIEWS, not random push access)
101 * changes to the policies (themes overlays, how to split overlay etc)
102 * changes to the tools (pointed out some specific things that are
103 already implemented in paludis)
104
105 I feel like I am repeating myself over and over again.
106
107 It's not just about "then work on it" if it's a cultural, organizational
108 and technical change at once.
109 The first step is NOT randomly implementing or changing things. The
110 first step is to discuss, find people who think similar and see if this
111 is even a thing we CAN move to.
112
113 Everything else (like improving our overlay tools) is really minor
114 compared to that. Saying I can go working on that right away is just a
115 polite/smart way to say "shut up".
116
117 >>
118 >> You don't understand. It's not just about blocking progress, it is about
119 >> _diverging_ ideas that cannot sanely be given as alternatives in a
120 >> SINGLE REPOSITORY.
121 >
122 > What is the difference between 1 million repositories on 1 million
123 > rsync servers and 1 million subdirectories on 1 rsync server?
124 > Administratively there is a difference, of course, but in terms of
125 > capability there is actually no difference. They're just different
126 > namespaces.
127 >
128
129 Then we should merge all upstream packages automatically into the CVS tree.
130
131 >>
132 >>> What I can't stand is people moping about their feelings being hurt
133 >>> from umpteen years ago. I can't go back and fix the past. Get over
134 >>> it - contribute or don't.
135 >>>
136 >>
137 >> This is rude. Please stick to the topic, it's not about my feelings.
138 >
139 > It wasn't directed at you specifically. I also didn't criticize
140 > anybody for having feelings. I criticized people for moping about
141 > them.
142 >
143 > It is just incredibly demotivating, and completely unactionable. If
144 > somebody a month ago gave you some misinformation about Nethack, I
145 > can't fix that. I gave you the correct information above.
146 >
147
148 Yes, it IS unactionable, because there is no consensus whatsoever. I
149 find it funny that people want to push me into the "go open a project
150 and shut up" direction.
151
152 Don't really expect me to push long for this. I don't need burn-out.
153
154 I am just pointing out the idea and waiting for interesting feedback
155 (majority wasn't).
156
157 >>
158 >> Again: there are various people who have a different concepts of how
159 >> games in gentoo should look like. So we can either start breaking tree
160 >> consistency (and I hope QA will kickban us for doing so, because that's
161 >> exactly their job) or we just stop doing everything centralized and let
162 >> things happen... which concept is the most popular one will then turn
163 >> out by itself!
164 >
165 > The council already said that games do not need to be in the games
166 > herd. It is not within the QA team's discretion to decide otherwise.
167 >
168 > BTW, about nethack: you can have a package named nethack2 if you
169 > want. I can add another one called nethack3. GLEP 39 specifically
170 > states that projects are allowed to compete.
171 >
172
173 "The Gentoo Quality Assurance Project aims to keep the portage tree in a
174 consistent state."
175
176 As I said: I don't think that GLEP makes a lot of sense. And I will
177 neither introduce competing eclasses, nor break tree consistency
178 randomly. The user will have major problems finding his way if we have
179 ~10 ruby eclasses, ~12 python eclasses, ~3 multilib implementations (uh,
180 we already have) and ~4 games eclasses (and some games not using any of
181 those).
182
183 Good job killing the tree.
184
185
186 >>> Don't get me wrong, I'm all for more overlay support. I'm all for
187 >>> reform when there is something to reform. However, in all your
188 >>> complaints about developers causing conflicts you're actually becoming
189 >>> part of the problem. You're basically coming across as being
190 >>> impossible to satisfy, because you bring up vague complaints without
191 >>> anything that anybody can act upon, and I find it rather frustrating
192 >>> personally as these sorts of issues are something I'm really committed
193 >>> to fixing.
194 >>>
195 >>
196 >> Again: you are confusing a specific incident with my proposal of a
197 >> distributed model.
198 >
199 > I FULLY support having more distributed repositories. The part of
200 > your argument that I object to is your claim that we have these huge
201 > cultural issues that prevent people from working on things they want
202 > to work on, or that we shouldn't allow people to work on packages in
203 > the main tree.
204 >
205
206 The reason I jumped into this thread is that someone had problems with
207 the java project. I'm not sure, but maybe something is wrong with my eyes?

Replies

Subject Author
Re: [gentoo-user] Gentoo's future directtion ? Rich Freeman <rich0@g.o>