1 |
On Wed, Nov 26, 2014 at 12:29 PM, hasufell <hasufell@g.o> wrote: |
2 |
> |
3 |
> That's a common misconception in gentoo. Someone has an idea and no one |
4 |
> cares until he "makes it happen". A lot of ideas are not so trivial that |
5 |
> you can just "make it happen". You need consensus, a shift of thinking, |
6 |
> workflow and maybe even that people work TOGETHER on that idea. |
7 |
> |
8 |
> But no, you keep saying "make it happen" and "by all means, start |
9 |
> working on it", completely ignoring the nature of the issues brought up. |
10 |
|
11 |
I think the issue is that 99% of the developer community doesn't think |
12 |
that there is anything seriously wrong. |
13 |
|
14 |
If you're waiting for a large mass of developers to decide to make a |
15 |
huge change, then you're just going to wait forever. All the packages |
16 |
I use work fine, and if one doesn't work I can fix it. For most |
17 |
Gentoo devs, that's all they're really expecting to get out of the |
18 |
distro. |
19 |
|
20 |
If you want to change the mindset, then you're going to have to do |
21 |
more than just talk about it on the lists. Historically things change |
22 |
in Gentoo when somebody builds something that is so obviously useful |
23 |
that just about everybody adopts it. For years we argued about why |
24 |
anybody should bother moving beyond EAPI0. Now it seems like the |
25 |
majority of the tree is EAPI5. That wasn't a policy change. It |
26 |
wasn't begging and pleading. It was the fact that slot operator |
27 |
dependencies happened and everybody saw the benefits to themselves of |
28 |
updating. |
29 |
|
30 |
> |
31 |
> I don't know of literally any big project except gentoo that still does |
32 |
> not _require_ a review workflow. Git would be the perfect excuse to |
33 |
> "make it happen", but that's something people have to agree on. |
34 |
> |
35 |
|
36 |
Gentoo is a release-less distro. First, most projects that aren't |
37 |
distros aren't really comparable to a linux distro because most |
38 |
projects represent something unified in design, while distros tend to |
39 |
be diverse collections. Distros that involve releases naturally |
40 |
involve review/testing/etc, as there is the concept that the release |
41 |
should be fairly free of bugs. In Gentoo there is no expectation that |
42 |
the distro is ever free of bugs - there is just WAY too much churn and |
43 |
there is never some kind of concept of overall quality. |
44 |
|
45 |
The other problem with a reviewer workflow is that most Gentoo devs |
46 |
don't want to be or deal with reviewers. It is hard enough to get |
47 |
maintainers to just not block collaboration entirely. |
48 |
|
49 |
If you want to do THAT big of a cultural change, you'd probably be |
50 |
better off just forking the distro, as you'll end up having to ditch |
51 |
almost all the current devs anyway. |
52 |
|
53 |
> |
54 |
> I don't think there is any hope left that this will become sane. |
55 |
|
56 |
If your vision of sanity is a world where all devs do nothing but |
57 |
review pull requests all day, I wouldn't have too much hope. I think |
58 |
it is a nice concept, but I just don't see it happening here. I |
59 |
wouldn't mind participating in it, but you're not going to get much |
60 |
support for banning the current way of doing things. |
61 |
|
62 |
The thing is, you don't have to ban direct commits to adopt a reviewer |
63 |
workflow. Just add the review-oriented workflow as an alternative to |
64 |
direct commits, and encourage its use. By all means try to recruit |
65 |
devs who will use the new workflow. If it is competitive it will |
66 |
flourish and nobody will mind its existence. Killing the status quo |
67 |
just makes it hard to go back if the new way doesn't work out, which |
68 |
makes it extremely risky. |
69 |
|
70 |
> |
71 |
> So, having 200+ core developers with push access is not just completely |
72 |
> wrong from the workflow perspective... it also makes it nearly |
73 |
> impossible to break with more fundamental concepts that are not |
74 |
> appropriate anymore. |
75 |
|
76 |
Hardly. You can let those 200+ core developers keep doing what |
77 |
they're doing, while you add your 20 more developers who can do the |
78 |
work of 500 developers using your new workflow. Time will clearly |
79 |
demonstrate which way works better. |
80 |
|
81 |
> |
82 |
> So, to reiterate: if you want to change more fundamental concepts in |
83 |
> gentoo, you need a job at google and be resistant to burn-out. And now |
84 |
> you are telling me nothing is wrong with our contribution culture? |
85 |
|
86 |
I think you need to think about why you contribute to Gentoo in the first place. |
87 |
|
88 |
If your goal of contributing is to get everybody else to do something |
89 |
differently then that is a MAJOR recipe for burnout. |
90 |
|
91 |
If your goal of contributing is to make somebody that nobody else is |
92 |
working on work better, then you're positioned to succeed. You can do |
93 |
that in whatever way you want, including getting others to contribute |
94 |
while you review the code, etc. You need to start small, and entice |
95 |
others to join you. |
96 |
|
97 |
-- |
98 |
Rich |