On 12/25/2009 06:10 AM, Denis Dupeyron wrote:
> On Sun, Dec 20, 2009 at 10:53 PM, Thomas Sachau <to...@gentoo.org> wrote:
>> I will make it short, since i already requested it 3 times, did create a 
>> thread at gentoo-dev ML:
>>
>> agenda topic: Discussion and approval for following item:
>>
>> Adding real multilib features from current multilib-portage to currently 
>> hardmasked and testing
>> portage-2.2* for wider testing, more eyes looking at it and hopefully more 
>> people helping improving
>> it, so we can get a version, which most can accept for PMS and maybe next 
>> EAPI.
> 
> Sorry, I forgot to send an email explaining what happened on the
> council alias as promised. The consensus was that the project wasn't
> mature enough to go ahead. Also more generally the council's job isn't
> discussing but deciding, approving, etc... Discussing is what should
> happen on mailing lists.

Since i see noone arguing against adding the multilib features to current 
testing branch of portage,
the discussion part already seems to be done. so a simple approval is ok, drop 
the discussion request.

> Before you can bring that to the council we
> need to see an as-much-as-possible finalized solution with any of the
> following if applicable: portage branch with an implementation that
> people can try, documentation, PMS patch, devmanual patches, and a
> team.

Did you actually read my lines? I did NOT request an ACK to add it to PMS and 
next EAPI with a
complete spec. zmedico also has no problem with having a look and adding it, 
but since he was once
forced to remove an added feature, he now wants a council-ok before adding and 
improving it in
testing branch of main tree portage.

> By team I mean: who is going to maintain this in the long run if
> necessary? A one man team is a dead team, it's only a matter of time.

Much code is maintained by a single person, even the package maintainers have 
one maintainer and
some contributors. And with integrating it in main tree portage, there will 
additionally be the
portage team.

> If the amd64 team is going to be the one doing this job, and this is
> just an example buy the way, then we need them to tell us they're OK
> with it.

If any other team raises its voice, no problem with me, but it seems more like 
noone wants to do the
work.

> Now don't get me wrong. I love your project and the last thing I want
> is to shoot it down.

In this case, you will shoot it down. I wont be able to maintain the code 
alone, do all requested
code changes, spec writing, PMS patches etc beside my work and other projects i 
do within Gentoo. So
if you stop me from getting help by integrating it in *testing* portage (not 
the 2.1.* versions,
only the 2.2* versions, which contains more and experimental code), it will 
probably stay at the
current level and nothing more will happen.
I can live myself with a private fork of portage, which contains the features i 
like, it is easy to
only do some basic changes and some workarounds to get it personally working 
without much time.
But on the other hand, all people, who would like to see emul-linux-* packages 
dropped, would like
to actually compile recent versions of 32bit libs and would like to compile 
additional libs not in
those emul-linux-* packages in addition to multi-ABI support for other ARCHes 
and multi-SLOT support
for the different languages (support parallel install for different SLOTS of 
e.g. python, perl or
ruby) would have to do their own local or eclass hacks to get their thing 
working.

> Look at what happened with prefix. They wanted
> the council to approve it immediately or else... We didn't cede to
> pressure and worked with them to make it good enough for approval.

Something like "I/We want <x>,<y>,<z> or you wont get an approval" is no 
support and no "work with
them". So if you really would like to see it in, actually help with patches, 
SPEC writing,
discussion and code writing. Else i request an approval for getting some 
additional help instead of
just shooting it down.

> Right now I don't hear anybody arguing about prefix going forward. And
> that's exactly what I want for your project, i.e. helping you making
> it better instead of it fading and failing in the (not so) long run.

prefix is no one-man-team and the actual amount of people, who can and are 
willing to work on
portage code is limited, so which other way do you have to improve it as 
requested?

And yes, it is frustrating to see 3 council sessions and months going by and 
still no offer to
support, no discussion, no patches and no decision is made. I can see now, why 
such project did die
before and why people dont want to do such things, which can actually improve 
the experience with
Gentoo and can give our userbase more options and choice.

> 
> I will stop now because I'm at a bus stop near Mount Fuji and I need
> to go. I hope the other council members, especially the more
> technically competent ones than me, will get back to you on this and
> offer help and advice. As soon as I have a better internet connection
> I will contact you about this.

Feel free to do so.

P.S.: I dont want to affront you or anyone else personally, but the way, how it 
currently goes. I
know from IRC, forums and mails, that there are people around, who would like 
to see
multilib-features in portage. But with such frustrating none-actions like this, 
noone should wonder
why such things are not implemented, also there are people, who would like to 
see it and even
people, who would help doing it and creating code for it. That does not 
actually speak for Gentoo,
more against it (and it is not the only point, where Gentoo could improve, but 
does not, but that
could be part of another big mail).


-- 
Thomas Sachau

Gentoo Linux Developer

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to