1 |
On Fri, Dec 25, 2009 at 8:00 AM, Thomas Sachau <tommy@g.o> wrote: |
2 |
> On 12/25/2009 06:10 AM, Denis Dupeyron wrote: |
3 |
>> On Sun, Dec 20, 2009 at 10:53 PM, Thomas Sachau <tommy@g.o> wrote: |
4 |
>>> I will make it short, since i already requested it 3 times, did create a thread at gentoo-dev ML: |
5 |
>>> |
6 |
>>> agenda topic: Discussion and approval for following item: |
7 |
>>> |
8 |
>>> Adding real multilib features from current multilib-portage to currently hardmasked and testing |
9 |
>>> portage-2.2* for wider testing, more eyes looking at it and hopefully more people helping improving |
10 |
>>> it, so we can get a version, which most can accept for PMS and maybe next EAPI. |
11 |
>> |
12 |
>> Sorry, I forgot to send an email explaining what happened on the |
13 |
>> council alias as promised. The consensus was that the project wasn't |
14 |
>> mature enough to go ahead. Also more generally the council's job isn't |
15 |
>> discussing but deciding, approving, etc... Discussing is what should |
16 |
>> happen on mailing lists. |
17 |
> |
18 |
> Since i see noone arguing against adding the multilib features to current testing branch of portage, |
19 |
> the discussion part already seems to be done. so a simple approval is ok, drop the discussion request. |
20 |
> |
21 |
>> Before you can bring that to the council we |
22 |
>> need to see an as-much-as-possible finalized solution with any of the |
23 |
>> following if applicable: portage branch with an implementation that |
24 |
>> people can try, documentation, PMS patch, devmanual patches, and a |
25 |
>> team. |
26 |
> |
27 |
> Did you actually read my lines? I did NOT request an ACK to add it to PMS and next EAPI with a |
28 |
> complete spec. zmedico also has no problem with having a look and adding it, but since he was once |
29 |
> forced to remove an added feature, he now wants a council-ok before adding and improving it in |
30 |
> testing branch of main tree portage. |
31 |
> |
32 |
>> By team I mean: who is going to maintain this in the long run if |
33 |
>> necessary? A one man team is a dead team, it's only a matter of time. |
34 |
> |
35 |
> Much code is maintained by a single person, even the package maintainers have one maintainer and |
36 |
> some contributors. And with integrating it in main tree portage, there will additionally be the |
37 |
> portage team. |
38 |
> |
39 |
>> If the amd64 team is going to be the one doing this job, and this is |
40 |
>> just an example buy the way, then we need them to tell us they're OK |
41 |
>> with it. |
42 |
> |
43 |
> If any other team raises its voice, no problem with me, but it seems more like noone wants to do the |
44 |
> work. |
45 |
> |
46 |
>> Now don't get me wrong. I love your project and the last thing I want |
47 |
>> is to shoot it down. |
48 |
> |
49 |
> In this case, you will shoot it down. I wont be able to maintain the code alone, do all requested |
50 |
> code changes, spec writing, PMS patches etc beside my work and other projects i do within Gentoo. So |
51 |
> if you stop me from getting help by integrating it in *testing* portage (not the 2.1.* versions, |
52 |
> only the 2.2* versions, which contains more and experimental code), it will probably stay at the |
53 |
> current level and nothing more will happen. |
54 |
> I can live myself with a private fork of portage, which contains the features i like, it is easy to |
55 |
> only do some basic changes and some workarounds to get it personally working without much time. |
56 |
> But on the other hand, all people, who would like to see emul-linux-* packages dropped, would like |
57 |
> to actually compile recent versions of 32bit libs and would like to compile additional libs not in |
58 |
> those emul-linux-* packages in addition to multi-ABI support for other ARCHes and multi-SLOT support |
59 |
> for the different languages (support parallel install for different SLOTS of e.g. python, perl or |
60 |
> ruby) would have to do their own local or eclass hacks to get their thing working. |
61 |
> |
62 |
>> Look at what happened with prefix. They wanted |
63 |
>> the council to approve it immediately or else... We didn't cede to |
64 |
>> pressure and worked with them to make it good enough for approval. |
65 |
> |
66 |
> Something like "I/We want <x>,<y>,<z> or you wont get an approval" is no support and no "work with |
67 |
> them". So if you really would like to see it in, actually help with patches, SPEC writing, |
68 |
> discussion and code writing. Else i request an approval for getting some additional help instead of |
69 |
> just shooting it down. |
70 |
> |
71 |
>> Right now I don't hear anybody arguing about prefix going forward. And |
72 |
>> that's exactly what I want for your project, i.e. helping you making |
73 |
>> it better instead of it fading and failing in the (not so) long run. |
74 |
> |
75 |
> prefix is no one-man-team and the actual amount of people, who can and are willing to work on |
76 |
> portage code is limited, so which other way do you have to improve it as requested? |
77 |
> |
78 |
> And yes, it is frustrating to see 3 council sessions and months going by and still no offer to |
79 |
> support, no discussion, no patches and no decision is made. I can see now, why such project did die |
80 |
> before and why people dont want to do such things, which can actually improve the experience with |
81 |
> Gentoo and can give our userbase more options and choice. |
82 |
> |
83 |
>> |
84 |
>> I will stop now because I'm at a bus stop near Mount Fuji and I need |
85 |
>> to go. I hope the other council members, especially the more |
86 |
>> technically competent ones than me, will get back to you on this and |
87 |
>> offer help and advice. As soon as I have a better internet connection |
88 |
>> I will contact you about this. |
89 |
> |
90 |
> Feel free to do so. |
91 |
> |
92 |
> P.S.: I dont want to affront you or anyone else personally, but the way, how it currently goes. I |
93 |
> know from IRC, forums and mails, that there are people around, who would like to see |
94 |
> multilib-features in portage. But with such frustrating none-actions like this, noone should wonder |
95 |
> why such things are not implemented, also there are people, who would like to see it and even |
96 |
> people, who would help doing it and creating code for it. That does not actually speak for Gentoo, |
97 |
> more against it (and it is not the only point, where Gentoo could improve, but does not, but that |
98 |
> could be part of another big mail). |
99 |
> |
100 |
> |
101 |
> -- |
102 |
> Thomas Sachau |
103 |
> |
104 |
> Gentoo Linux Developer |
105 |
> |
106 |
> |
107 |
|
108 |
People are honestly just waiting for this to hit the tree at this |
109 |
point. Inaction by the council is a serious failure of the council. |
110 |
The Portage team doesn't want to start integrating code that the |
111 |
council will force them to remove in the future. Being a former |
112 |
council member myself I can easily say, get off your ass and do |
113 |
something. |
114 |
|
115 |
-- |
116 |
Doug Goldstein |