Gentoo Archives: gentoo-dev

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

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies