1 |
On Sun, Nov 23, 2014 at 6:45 PM, hasufell <hasufell@g.o> wrote: |
2 |
>> |
3 |
>> As long as you actually commit to maintaining the Nethack package, you |
4 |
>> can do this. |
5 |
>> |
6 |
> |
7 |
> As above: I think it's wrong. |
8 |
> |
9 |
|
10 |
Your opinion is noted. Your argument was that policy issues were |
11 |
preventing you from fixing Nethack. Now you're simply choosing not to |
12 |
fix Nethack because you think that the problem was fixed in the wrong |
13 |
way. |
14 |
|
15 |
You're welcome to not fix Nethack if you don't want to fix it. |
16 |
However, it is a bit disingenuous to talk about barriers to fixing |
17 |
things when they're self-imposed. |
18 |
|
19 |
> |
20 |
> I have offered one right now, including |
21 |
> * changes to the project structure (shrinking the amount of devs, |
22 |
> concentrating on the core, base-system, toolchain, PM) |
23 |
|
24 |
Nobody is going to deny devs entry to Gentoo in the absence of a |
25 |
working alternative. That just seems like a non-starter. Create your |
26 |
grand new vision first, then you probably won't have to convince |
27 |
everybody else to abandon the status quo. |
28 |
|
29 |
> * changes to the culture (REVIEWS, not random push access) |
30 |
> * changes to the policies (themes overlays, how to split overlay etc) |
31 |
> * changes to the tools (pointed out some specific things that are |
32 |
> already implemented in paludis) |
33 |
|
34 |
These are all things I support. |
35 |
|
36 |
> It's not just about "then work on it" if it's a cultural, organizational |
37 |
> and technical change at once. |
38 |
|
39 |
Sure it is. That is how things get solved. |
40 |
|
41 |
Your proposal amounts to basically forking the whole distro. You can |
42 |
do that if you want. We're not going to force it to happen by kicking |
43 |
all the current devs out. |
44 |
|
45 |
> The first step is NOT randomly implementing or changing things. The |
46 |
> first step is to discuss, find people who think similar and see if this |
47 |
> is even a thing we CAN move to. |
48 |
|
49 |
No argument, and I fully support that discussion. I just don't care |
50 |
for the "sky is falling" atmosphere. |
51 |
|
52 |
>> |
53 |
>> What is the difference between 1 million repositories on 1 million |
54 |
>> rsync servers and 1 million subdirectories on 1 rsync server? |
55 |
>> Administratively there is a difference, of course, but in terms of |
56 |
>> capability there is actually no difference. They're just different |
57 |
>> namespaces. |
58 |
>> |
59 |
> |
60 |
> Then we should merge all upstream packages automatically into the CVS tree. |
61 |
|
62 |
As I said, administratively there is a difference, and technically |
63 |
there is not (in the sense of technical capability). That is just as |
64 |
true about forking every single upstream project we have and sticking |
65 |
it in CVS. That would actually work just fine technically. It just |
66 |
would be a horrible mess to administer. |
67 |
|
68 |
>> |
69 |
>> It is just incredibly demotivating, and completely unactionable. If |
70 |
>> somebody a month ago gave you some misinformation about Nethack, I |
71 |
>> can't fix that. I gave you the correct information above. |
72 |
>> |
73 |
> |
74 |
> Yes, it IS unactionable, because there is no consensus whatsoever. I |
75 |
> find it funny that people want to push me into the "go open a project |
76 |
> and shut up" direction. |
77 |
> |
78 |
> Don't really expect me to push long for this. I don't need burn-out. |
79 |
> |
80 |
> I am just pointing out the idea and waiting for interesting feedback |
81 |
> (majority wasn't). |
82 |
|
83 |
I'm all for improvements. The part that is demotivating is pointing |
84 |
to past problems that are solved and arguing that we still need to |
85 |
solve them. Then talking about non-specific problems that need |
86 |
solutions, without giving anybody an opportunity to solve it in any |
87 |
other way. |
88 |
|
89 |
It is just unfair to everybody to argue in this way. |
90 |
|
91 |
Suppose I claim that Gentoo has horrible problems, but it will all be |
92 |
fixed if everybody mails me a check for $10k. What are those |
93 |
problems? Well, they are cultural problems. They're really serious. |
94 |
They're making people quit! Who specifically is quitting? You're |
95 |
focusing on specifics, and I'm trying to fix the big problems and not |
96 |
the little instances of it. Just send me that check for $10k. |
97 |
|
98 |
I ask for specifics because as a Council member it is my duty to try |
99 |
to deal with problems. When you claim that there are problems not |
100 |
getting solved, but refuse to provide the necessary information to |
101 |
allow the problems to be solved, then it is basically an argument that |
102 |
I'm not doing my job and you're dissatisfied, but you simply don't |
103 |
trust me to actually fix things. |
104 |
|
105 |
I realize that is personalizing things a bit, but it is demotivating |
106 |
all the same. |
107 |
|
108 |
I fully get that your intentions are good. I'm not disputing that. |
109 |
However, you're proposing revolutionary solutions that are unlikely to |
110 |
be embraced wholesale when having a long-term goal with incremental |
111 |
steps for getting there would be far more constructive. |
112 |
|
113 |
> |
114 |
>>> |
115 |
>>> Again: there are various people who have a different concepts of how |
116 |
>>> games in gentoo should look like. So we can either start breaking tree |
117 |
>>> consistency (and I hope QA will kickban us for doing so, because that's |
118 |
>>> exactly their job) or we just stop doing everything centralized and let |
119 |
>>> things happen... which concept is the most popular one will then turn |
120 |
>>> out by itself! |
121 |
>> |
122 |
>> The council already said that games do not need to be in the games |
123 |
>> herd. It is not within the QA team's discretion to decide otherwise. |
124 |
>> |
125 |
>> BTW, about nethack: you can have a package named nethack2 if you |
126 |
>> want. I can add another one called nethack3. GLEP 39 specifically |
127 |
>> states that projects are allowed to compete. |
128 |
>> |
129 |
> |
130 |
> "The Gentoo Quality Assurance Project aims to keep the portage tree in a |
131 |
> consistent state." |
132 |
> |
133 |
> As I said: I don't think that GLEP makes a lot of sense. And I will |
134 |
> neither introduce competing eclasses, nor break tree consistency |
135 |
> randomly. The user will have major problems finding his way if we have |
136 |
> ~10 ruby eclasses, ~12 python eclasses, ~3 multilib implementations (uh, |
137 |
> we already have) and ~4 games eclasses (and some games not using any of |
138 |
> those). |
139 |
> |
140 |
|
141 |
We already have 2 multilib implementations, and 2 approaches to games. |
142 |
|
143 |
Your proposed distributed model would actually increase the number of |
144 |
alternatives. |
145 |
|
146 |
> |
147 |
>>>> Don't get me wrong, I'm all for more overlay support. I'm all for |
148 |
>>>> reform when there is something to reform. However, in all your |
149 |
>>>> complaints about developers causing conflicts you're actually becoming |
150 |
>>>> part of the problem. You're basically coming across as being |
151 |
>>>> impossible to satisfy, because you bring up vague complaints without |
152 |
>>>> anything that anybody can act upon, and I find it rather frustrating |
153 |
>>>> personally as these sorts of issues are something I'm really committed |
154 |
>>>> to fixing. |
155 |
>>>> |
156 |
>>> |
157 |
>>> Again: you are confusing a specific incident with my proposal of a |
158 |
>>> distributed model. |
159 |
>> |
160 |
>> I FULLY support having more distributed repositories. The part of |
161 |
>> your argument that I object to is your claim that we have these huge |
162 |
>> cultural issues that prevent people from working on things they want |
163 |
>> to work on, or that we shouldn't allow people to work on packages in |
164 |
>> the main tree. |
165 |
>> |
166 |
> |
167 |
> The reason I jumped into this thread is that someone had problems with |
168 |
> the java project. I'm not sure, but maybe something is wrong with my eyes? |
169 |
|
170 |
And my point was that the only problem I see with Java is that nobody |
171 |
is actually working on it. If nobody works on distributed java |
172 |
repositories, it will be just as bad. |
173 |
|
174 |
My specific request was WHO is trying to do something to improve Java |
175 |
and finding a policy that is preventing them from doing so, and WHAT |
176 |
policy is causing the problem? |
177 |
|
178 |
It is easy to talk about vague problems. It is harder to actually |
179 |
pinpoint specific issues that can actually be fixed. |
180 |
|
181 |
Please don't take this as a personal attack - I generally have a lot |
182 |
of respect for you. I just don't think that this is a helpful way of |
183 |
approaching these problems. |
184 |
|
185 |
-- |
186 |
Rich |