Gentoo Archives: gentoo-council

From: Doug Goldstein <cardoe@g.o>
To: gentoo-dev@l.g.o
Cc: Denis Dupeyron <calchan@g.o>, gentoo-council <gentoo-council@l.g.o>
Subject: [gentoo-council] Re: [gentoo-dev] Re: [gentoo-dev-announce] January 2010 meeting date
Date: Sat, 26 Dec 2009 03:28:57
Message-Id: eafa4c130912251928qfe63ed4g96577b78eef4a05d@mail.gmail.com
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