1 |
On Sat, Nov 22, 2014 at 06:20:01PM -0500, Rich Freeman wrote: |
2 |
|
3 |
> Don't get me wrong, I'm all for more overlay support. I'm all for |
4 |
> reform when there is something to reform. However, in all your |
5 |
> complaints about developers causing conflicts you're actually becoming |
6 |
> part of the problem. |
7 |
|
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 |
Nicolas Sebrecht |