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? |