1 |
On Sat, Nov 22, 2014 at 5:44 PM, hasufell <hasufell@g.o> wrote: |
2 |
> On 11/22/2014 11:20 PM, Rich Freeman wrote: |
3 |
>> |
4 |
>> Nobody can block progress under the current model. If you feel |
5 |
>> otherwise, please point them out so that they can be dealt with. |
6 |
>> |
7 |
> |
8 |
> They can block progress and they do. And by saying we allow conflicting |
9 |
> ideas in one repository we are even making it worse. |
10 |
> |
11 |
> The council is a workaround to make the broken project structure not |
12 |
> look too bad. |
13 |
|
14 |
What do you do if somebody blocks progress in your overlay structure? |
15 |
You start another one. |
16 |
|
17 |
What do you do if somebody blocks progress in the current Gentoo |
18 |
project structure? You either ask the Council for help, or start |
19 |
another project. |
20 |
|
21 |
You have just as many options under the status quo, and actually more. |
22 |
|
23 |
Now, what you would get is the ability to have more variety in quality |
24 |
standards, since general QA/etc would not apply. |
25 |
|
26 |
> |
27 |
> I strongly disagree. I know a fair amount of games overlays where people |
28 |
> do work on games ebuilds. They just don't give a sh*t anymore to try to |
29 |
> get that stuff into the main tree, because they were alienated long ago. |
30 |
|
31 |
Well, then by your argument there is nothing wrong, since they're |
32 |
already in the distributed model. There is nothing I can do about |
33 |
people feeling alienated. |
34 |
|
35 |
If you want to contribute to Gentoo, then do it. If somebody blocks |
36 |
your progress then ask for help. |
37 |
|
38 |
What I can't stand is people moping about their feelings being hurt |
39 |
from umpteen years ago. I can't go back and fix the past. Get over |
40 |
it - contribute or don't. |
41 |
|
42 |
> |
43 |
> The image of the games team is so bad, that not even gentoo devs bother |
44 |
> anymore (except me, uh). Yet neither the council, nor comrel has done |
45 |
> anything radical, except giving recommendations, asking for them to |
46 |
> elect a new lead, blah blah. |
47 |
|
48 |
The games team has ZERO power over any dev doing anything to any |
49 |
package in the tree. That was the outcome of the most recent Council |
50 |
decision. We didn't disband the team because we thought that having a |
51 |
team focused on games wasn't a bad idea, but so far nobody else seems |
52 |
all that interested so it seems as likely as not that there won't be a |
53 |
games team in the future. |
54 |
|
55 |
How is that not doing something radical? What more do you want us to do? |
56 |
|
57 |
> |
58 |
> It's not about elitist old-timers, it's about a more dynamic model that |
59 |
> has low tolerance for |
60 |
> * bugs being open since 8+ years, because no one bothers to |
61 |
> review/change stuff (check nethack bug) |
62 |
> * territorial behaviour |
63 |
> * slacking devs slacking so hard, but not stepping down |
64 |
|
65 |
The reason the nethack bug is still open is because nobody cares |
66 |
enough to fix it. ANYBODY can make themselves a maintainer of Nethack |
67 |
right now and fix the bug. The reason that the Nethack bug is still |
68 |
open is because you apparently care enough about it to post about it, |
69 |
but not enough to fix it. I'm not going to fix it, because I don't |
70 |
use Nethack. |
71 |
|
72 |
The issues you bring up were an issue in the past, and nobody really |
73 |
has any tolerance for it these days. You keep bringing up past issues |
74 |
that have been fixed, which really sounds to me like a demonstration |
75 |
that we're running out of real current issues to fix. |
76 |
|
77 |
If there is somebody blocking progress on something, by all means |
78 |
point it out. However, it needs to be a case where somebody is |
79 |
actually trying to do something, not just complaints about all the |
80 |
great stuff that could get done if somebody cared enough to even try. |
81 |
|
82 |
> |
83 |
> In addition, this model requires a workflow that is long overdue, |
84 |
> including proper VCS like git or mercurial and a review culture. None of |
85 |
> this happens on a larger scale. Instead we are stuck with tools like |
86 |
> bugzilla for ebuild reviews and push our happy ebuilds to the CVS |
87 |
> repository. |
88 |
|
89 |
Sounds great. Looking forward to your contributions to the git |
90 |
migration, which by all indications is just about done. Maybe you |
91 |
could get started on a gerrit front-end or something. |
92 |
|
93 |
> |
94 |
> So now guess again why people don't bother, because: |
95 |
> * have to become gentoo devs over a period of 6 months or so, then |
96 |
> realize they are stuck with territorial crap, people ignoring each other |
97 |
> and have to appeal to the council, comrel or whoever multiple times |
98 |
> before something happens? |
99 |
|
100 |
Most of this stuff is fixed, and every issue that has come up in the |
101 |
last year has been resolved in the course of a single Council meeting. |
102 |
Please cite an example to the contrary. Having attended just about |
103 |
every Council meeting in the last year I can cite plenty of cases |
104 |
where stuff like this was fixed. |
105 |
|
106 |
> * or they have to write bugs reports on bugzilla, attach ebuilds |
107 |
> manually, get a partly review in a timeframe of 9 months if they are |
108 |
> lucky, re-push attachments, start again |
109 |
> * or they can try to contribute to sunrise which may be simirlarly slow |
110 |
> (mind you, I've been a sunrise dev, so we can talk about that if you like) |
111 |
> * or they just start their own overlay and stop caring to collaborate |
112 |
> with gentoo devs |
113 |
|
114 |
You realize that the last point is basically your proposed solution. |
115 |
If they don't want to do this today, why would they want to do it |
116 |
tomorrow? They're not going to be collaborating with Gentoo devs |
117 |
under your model, since there won't be all that many of them to |
118 |
collaborate with. |
119 |
|
120 |
> * If they are very lucky, then their favorite project already uses an |
121 |
> overlay-workflow (e.g. haskell, science). And those projects usually are |
122 |
> so slow with moving their overlay ebuilds into the tree, that it's |
123 |
> almost useless doing so. They should just stop and focus on their overlays. |
124 |
> |
125 |
|
126 |
The problem is that most of the overlays don't support everything in |
127 |
the main tree. For example, right now it is REALLY painful to run qt5 |
128 |
on a stable box, because the qt5 overlay just introduced changes |
129 |
making it incompatible with stable qt4. That sort of thing is likely |
130 |
to get worse rather than better in a distributed model. |
131 |
|
132 |
Don't get me wrong, I'm all for more overlay support. I'm all for |
133 |
reform when there is something to reform. However, in all your |
134 |
complaints about developers causing conflicts you're actually becoming |
135 |
part of the problem. You're basically coming across as being |
136 |
impossible to satisfy, because you bring up vague complaints without |
137 |
anything that anybody can act upon, and I find it rather frustrating |
138 |
personally as these sorts of issues are something I'm really committed |
139 |
to fixing. |
140 |
|
141 |
-- |
142 |
Rich |