1 |
James: |
2 |
> hasufell <hasufell <at> gentoo.org> writes: |
3 |
> |
4 |
> |
5 |
>> I still don't see a good argument why we made our system so inflexible, |
6 |
>> that obviously needed change needs such high amount of work, PR and proof. |
7 |
> |
8 |
> I think that most folks appreciate your efforts and insightful ideas |
9 |
> on how to open up development, particularly in non-critical (non-core) |
10 |
> areas. The quesiton is how do we get from where we are to where we |
11 |
> want to be. I find most of what I'm interested in already in Arch Linux. I |
12 |
> wonder why it is so much easier for Arch users to create pkgbuilds (like |
13 |
> gentoo's ebuilds) and find a dev to adopt the package? Surely someone has |
14 |
> some insight on this differences, or do I miss something that creats the |
15 |
> difference? [1] I also find the Arch documentation to be of the finest |
16 |
> quality of any and all linux distros, close to gentoo. ymmv. |
17 |
> |
18 |
> |
19 |
|
20 |
Arch has done it wrong, IMO. Sure, their PKGBUILDs are easier to write, |
21 |
but their quality is also worse. I know how to write them and have |
22 |
written and looked at a lot of them. |
23 |
|
24 |
People went the easy way and didn't really care much about review |
25 |
workflow, so they ended up with AUR where everyone can upload random |
26 |
stuff, including dangerous and wrong code. |
27 |
|
28 |
>> Trying to improve a tiny fraction about gentoo workflow (including your |
29 |
>> attempts) already took more than 4(?) years with never ending excuses. |
30 |
>> The necessity was more than obvious. |
31 |
>> Now I could talk about similarly obvious things. Sure, not all issues |
32 |
>> are obvious and those shouldn't be easy to push through. |
33 |
> |
34 |
> |
35 |
> Everyone understands small changes and all changes take time for the |
36 |
> majority of members to digest, imho. Not everyone has your keen insight into |
37 |
> the problem/opportunity. So your patience in explanation, encouragement and |
38 |
> solicitation, is very important, if your idea is to be |
39 |
> implemented and tested. Naturally, Rich and other deeply involved devs, with |
40 |
> addtional responsibilities exude caution, to keep the gentoo stable. |
41 |
> They will not be the source of "team building" for your idea, imho. |
42 |
> |
43 |
|
44 |
Gentoo isn't even particularly stable anymore. It's a mess to maintain |
45 |
with a confused PM, toolchain hackery and random conflicting ideas in |
46 |
one repository (e.g. multilib clashing with crossdev). |
47 |
|
48 |
The distro can only be as stable as the PM and the PM depends on the |
49 |
input. The input depends on quality ebuilds. Quality ebuilds depend on a |
50 |
proper spec, but there is no proper spec... PMS team itself says it |
51 |
started as a collection of ancient portage behavior and then grew with |
52 |
time, so there was no real design behind it. Quality ebuilds also depend |
53 |
on review-workflow. Review-workflow needs proper tools. |
54 |
|
55 |
We don't even have the last one. Long way to go. Good luck. |
56 |
|
57 |
|
58 |
>> You can draw your conclusions about this. I drew mine: small changes |
59 |
>> will not get us out of here. |
60 |
> |
61 |
> |
62 |
> I think the jury is still out. So, why can't we test a transient plan |
63 |
> where we take something very broken areas at Gentoo (games or java or |
64 |
> sys-cluster) and test out your hypothesis for package development expansion? |
65 |
> |
66 |
|
67 |
Already doing so |
68 |
https://github.com/hasufell/games-overlay |
69 |
|
70 |
and that's where I will update ebuilds, not in the tree. And I don't |
71 |
care to get any of that into the tree. |
72 |
|
73 |
> In fact, I've been looking over quite a few ebuilds and pkgbuilds at (Arch |
74 |
> linux). [2] I see quite a lot of commonality. So, why can we not "modify" |
75 |
> this aforementioned "inflexible" system on gentoo to allow for Arch Linux |
76 |
> pkgbuilds to be routinely compiled and installed on gentoo? |
77 |
> |
78 |
> Maybe limit the test to /usr/local/portage or /usr/local/portage/test/ so |
79 |
> folks can participate or purge the experiment? Maybe find some Arch linux |
80 |
> devs keen on the idea of developing/evolving package management so that |
81 |
> the two distros can readiy (or more easily) convert packages between |
82 |
> Arch and Gentoo? Is it possible? Could your plan be modified to |
83 |
> include a variety of Arch developers? Surely you have a collection |
84 |
> of devs ready to implement your keen ideas? I, for one realize something |
85 |
> fundamental has to change with Gentoo, after pushing a few months |
86 |
> on java and cluster codes.... Also, there is a vast array of software, |
87 |
> of various quality, among the overlay repositories to use as test-packages? |
88 |
> |
89 |
> |
90 |
> The biggest thing I seen wrong with Arch is they have forced systemd |
91 |
> onto their users, and all of the arch users I know, are not very |
92 |
> happy about that. So if you approach this correctly, I'm sure quite a |
93 |
> few Arch linux folks would also test your offerings. |
94 |
> |
95 |
>> Have fun, if you can. |
96 |
> |
97 |
> |
98 |
> Always we should have fun. That is why we should deeply discuss these |
99 |
> issues to find common ground. Maybe fixing this inflexible system should |
100 |
> involve a survey of those distros closest to gentoo, for ideas, particulary |
101 |
> several (structured) methods to install packages, provide choices for the |
102 |
> init system, and strongly advocate package development within the |
103 |
> ranks of the user base. Clear and concise documentation, concurrent with |
104 |
> this effort is probably your single greatest alley, should your idea |
105 |
> and leadership prove successful. |
106 |
> |
107 |
> |
108 |
|
109 |
People are scared of other gentoo-like distros/PMs. Exherbo is evil, |
110 |
paludis is evil, sabayoon is evil, ... |
111 |
|
112 |
I've already tried contributing to exherbo. They are technically ahead |
113 |
of us in some non-trivial areas, but I don't think they have solved the |
114 |
contribution problem. Sure, they are more distributed and have gerrit |
115 |
etc, but their review workflow goes more the way "make a high-quality |
116 |
user-overlay and then we will review it once and add it to our page". |
117 |
|
118 |
They don't care too much about themed and clearly scoped overlays and |
119 |
about the difference of 'modular' and 'fragmented'. |
120 |
|
121 |
200 guys pushing into 200 repositories without _regular_ reviews (not |
122 |
just a "gentoo dev" or "high quality" overlay badge) is not much |
123 |
different to what gentoo does. |
124 |
|
125 |
Arch is neither interesting from the technical nor from the workflow |
126 |
standpoint, IMO. |