Gentoo Logo
Gentoo Spaceship

Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-council
Lists: gentoo-council: < Prev By Thread Next > < Prev By Date Next >
To: gentoo-dev@g.o
From: Doug Goldstein <cardoe@g.o>
Subject: Re: [gentoo-dev] Re: [gentoo-dev-announce] January 2010 meeting date
Date: Fri, 25 Dec 2009 21:28:50 -0600
On Fri, Dec 25, 2009 at 8:00 AM, Thomas Sachau <tommy@g.o> wrote:
> On 12/25/2009 06:10 AM, Denis Dupeyron wrote:
>> On Sun, Dec 20, 2009 at 10:53 PM, Thomas Sachau <tommy@g.o> 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

People are honestly just waiting for this to hit the tree at this
point. Inaction by the council is a serious failure of the council.
The Portage team doesn't want to start integrating code that the
council will force them to remove in the future. Being a former
council member myself I can easily say, get off your ass and do

Doug Goldstein

January 2010 meeting date
-- Denis Dupeyron
Re: [gentoo-dev-announce] January 2010 meeting date
-- Denis Dupeyron
Lists: gentoo-council: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: [gentoo-dev-announce] January 2010 meeting date
Next by thread:
Re: [gentoo-dev] Re: [gentoo-dev-announce] January 2010 meeting date
Previous by date:
Re: [gentoo-dev-announce] January 2010 meeting date
Next by date:
Improving Council operations with a web application

Updated Nov 13, 2011

Summary: Archive of the gentoo-council mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.