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 1NOAzc-00068B-HI for garchives@archives.gentoo.org; Fri, 25 Dec 2009 14:18:12 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 219BEE0874 for ; Fri, 25 Dec 2009 14:18:12 +0000 (UTC) Received: from tommyserver.de (unknown [85.14.198.50]) by pigeon.gentoo.org (Postfix) with ESMTP id 7F6C2E050E; Fri, 25 Dec 2009 14:00:56 +0000 (UTC) Received: from [192.168.178.22] (p4FDF0AF7.dip0.t-ipconnect.de [79.223.10.247]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tommyserver.de (Postfix) with ESMTPSA id E7D5D1A33D; Fri, 25 Dec 2009 15:00:52 +0100 (CET) Message-ID: <4B34C584.6070307@gentoo.org> Date: Fri, 25 Dec 2009 15:00:36 +0100 From: Thomas Sachau 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 To: Denis Dupeyron CC: gentoo-council , gentoo-dev@lists.gentoo.org Subject: [gentoo-dev] Re: [gentoo-dev-announce] January 2010 meeting date References: <7c612fc60912150854k608270cag61c533542075f5bf@mail.gmail.com> <4B2E2C59.3070004@gentoo.org> <7c612fc60912242110o32918b04t2e477a1573290a36@mail.gmail.com> In-Reply-To: <7c612fc60912242110o32918b04t2e477a1573290a36@mail.gmail.com> X-Enigmail-Version: 1.0 OpenPGP: id=211CA2D4 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig9CEA8D2BD078A750011C5C66" X-Archives-Salt: 75b999cd-7887-4c55-8e0f-526dff1890f2 X-Archives-Hash: cf1b2ed56901ade39d6c08d48f377b14 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9CEA8D2BD078A750011C5C66 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 12/25/2009 06:10 AM, Denis Dupeyron wrote: > On Sun, Dec 20, 2009 at 10:53 PM, Thomas Sachau wrot= e: >> 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 current= ly 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 n= ext EAPI. >=20 > 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 addin= g 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 wi= ll 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 proj= ects 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 wi= ll probably stay at the current level and nothing more will happen. I can live myself with a private fork of portage, which contains the feat= ures i like, it is easy to only do some basic changes and some workarounds to get it personally work= ing without much time. But on the other hand, all people, who would like to see emul-linux-* pac= kages dropped, would like to actually compile recent versions of 32bit libs and would like to compi= le additional libs not in those emul-linux-* packages in addition to multi-ABI support for other AR= CHes 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 patch= es, 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 ar= e 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 imp= rove the experience with Gentoo and can give our userbase more options and choice. >=20 > 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 lik= e to see it and even people, who would help doing it and creating code for it. That does not a= ctually 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). --=20 Thomas Sachau Gentoo Linux Developer --------------enig9CEA8D2BD078A750011C5C66 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iJwEAQEKAAYFAks0xYoACgkQG7kqcTWJkGeJPwP/dh6UrW9Le4oanthq+UEztebS WCliBMHxp433hOgr3yz6DiDQbpLzqULR4N4OKdgspOu2P2+fRprBXlEryqew2d3G 29FwMFJDvGk78n6m3Ly7x2qsw0zPqcDrMa7fx66vFuhJDM1mAewxsmmhPzVpAlvN elVbX7NwQN1ao4c2mZc= =2Nrz -----END PGP SIGNATURE----- --------------enig9CEA8D2BD078A750011C5C66--