Gentoo Archives: gentoo-user

From: Rich Freeman <rich0@g.o>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] Gentoo's future directtion ?
Date: Wed, 26 Nov 2014 18:04:22
Message-Id: CAGfcS_kAtSHGyX52AxUAu_JbORvxfwgbW5tX_yCWLL8=j=7Y3Q@mail.gmail.com
In Reply to: Re: [gentoo-user] Gentoo's future directtion ? by hasufell
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

Replies

Subject Author
Re: [gentoo-user] Gentoo's future directtion ? hasufell <hasufell@g.o>
Re: [gentoo-user] Gentoo's future directtion ? konsolebox <konsolebox@×××××.com>