Gentoo Archives: gentoo-user

From: Volker Armin Hemmann <volkerarmin@××××××××××.com>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] Re: Gentoo's future directtion ?
Date: Sun, 23 Nov 2014 15:31:55
Message-Id: 5471FDE1.2040108@googlemail.com
In Reply to: [gentoo-user] Re: Gentoo's future directtion ? by Nicolas Sebrecht
1 Am 23.11.2014 um 16:18 schrieb Nicolas Sebrecht:
2 > On Sat, Nov 22, 2014 at 06:20:01PM -0500, Rich Freeman wrote:
3 >
4 >> Don't get me wrong, I'm all for more overlay support. I'm all for
5 >> reform when there is something to reform. However, in all your
6 >> complaints about developers causing conflicts you're actually becoming
7 >> part of the problem.
8 > I'd say the problem is not about the devs themselves causing conflicts
9 > but the environment and frame devs are working in the current workflow.
10 > Everybody look baffled with the current way of doing things in Gentoo.
11 >
12 > I agree with hasukel that the "distributed Gentoo" as proposed today is
13 > a wrong answer. Not that the issues raised are not valid. They do.
14 >
15 > Also, I agree with hasukel that the main problem is about having a
16 > correct distributed model. Posting on bugzilla for ebuilds updates or
17 > new ebuilds is seriously damaging when almost every where else it is
18 > just about sending your git patches. Becoming an official Gentoo dev is
19 > not a solution either due to the recruiting process.
20 >
21 > As you say, official devs can work on whatever they like and their
22 > contributions will likely hit the users at some point while at the same
23 > time occasional devs are asked to work with old tools like bugzilla. So
24 > yes, the whole review process is broken and the contribution process is
25 > broken too.
26 >
27 > About that, there's no other way than break the whole recruiting process
28 > and change of tools. Have your core team handle git repositories and let
29 > others request pull or send patches like almost all the other open
30 > source softwares in the world. Let's exploit the anarchy and openness
31 > instead of partitionning things into devs/non-devs or main-tree/overlays.
32 >
33 >
34 > Back to the original request. Here is how starts the "distributed
35 > Gentoo" model:
36 >
37 > Imagine you would say "I like gentoo, but I don't like the way the
38 > toolchain is handled, so I want to do it differently". Currently, your
39 > only way is to fork the whole distro or do dangerous stuff with
40 > overlays.
41 >
42 > Imagine gentoo would actually be a small repository of core packages
43 > with lots of optional user contributed extenions of all kinds. You'd
44 > only need to fork the core and add those extensions you like.
45 >
46 > Similarly... you don't like the way ruby is handled? Well, apart from
47 > dev-lang/ruby maybe, there'd be no ruby gems in the tree anyway. So
48 > there can be different approaches of packaging ruby gems and you choose
49 > which to use or if you want to do it completely different. And there
50 > would be no complicated configuration required to prevent in-tree ruby
51 > packages getting pulled in, because there are none.
52 >
53 > Isn't this all stuff about handling some kind of pointers? Don't like
54 > the toolchain? Point to another one. Don't like the way ruby is handled?
55 > Point to another one.
56 >
57 > So, is it about overlays? No. I'd say overlays are some kind of poor
58 > pointers for many reasons.
59 >
60 > Hence, why not adding the pointers we are all missing and rethinking the
61 > other pointers?
62 >
63
64 am I the only one who thinks that this way leads to madness?
65
66 Version conflicts are bad enough. No multiply that with a bunch of
67 overlays, all having their own libXY with just some tiny, tiny
68 differences, and another bunch of overlays who want libXY from certain
69 others....
70
71 if that does not give you nightmares, I don't know what.

Replies

Subject Author
[gentoo-user] Re: Gentoo's future directtion ? Nicolas Sebrecht <nicolas.s-dev@×××××××.net>