From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1NONuX-0007hr-Nk for garchives@archives.gentoo.org; Sat, 26 Dec 2009 04:05:50 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 598B8E0759 for ; Sat, 26 Dec 2009 04:05:49 +0000 (UTC) Received: from mail-px0-f195.google.com (mail-px0-f195.google.com [209.85.216.195]) by pigeon.gentoo.org (Postfix) with ESMTP id 2D219E0880; Sat, 26 Dec 2009 03:28:51 +0000 (UTC) Received: by pxi33 with SMTP id 33so6116737pxi.10 for ; Fri, 25 Dec 2009 19:28:50 -0800 (PST) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Sender: cardoe@cardoe.com Received: by 10.143.20.13 with SMTP id x13mr8118088wfi.55.1261798130543; Fri, 25 Dec 2009 19:28:50 -0800 (PST) In-Reply-To: <4B34C584.6070307@gentoo.org> References: <7c612fc60912150854k608270cag61c533542075f5bf@mail.gmail.com> <4B2E2C59.3070004@gentoo.org> <7c612fc60912242110o32918b04t2e477a1573290a36@mail.gmail.com> <4B34C584.6070307@gentoo.org> Date: Fri, 25 Dec 2009 21:28:50 -0600 X-Google-Sender-Auth: 44863aeed88ca385 Message-ID: Subject: Re: [gentoo-dev] Re: [gentoo-dev-announce] January 2010 meeting date From: Doug Goldstein To: gentoo-dev@lists.gentoo.org Cc: Denis Dupeyron , gentoo-council Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: 602d0ecc-4e18-4e15-81c8-c6d423ee222b X-Archives-Hash: 3e81b3dca68d052ab72b0ead82a89677 On Fri, Dec 25, 2009 at 8:00 AM, Thomas Sachau wrote: > On 12/25/2009 06:10 AM, Denis Dupeyron wrote: >> On Sun, Dec 20, 2009 at 10:53 PM, Thomas Sachau 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 ,, 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 something. -- Doug Goldstein