[gentoo-dev] Re: [gentoo-dev-announce] January 2010 meeting date

2009-12-25 Thread Thomas Sachau
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 

Re: [gentoo-dev] Last rites for net-dns/ldapdns

2009-12-25 Thread Joshua Saddler
On Wed, 23 Dec 2009 10:40:06 -0600
Victor Ostorga vosto...@gentoo.org wrote:

 
 # Víctor Ostorga vosto...@gentoo.org (23 Dec 2009)
 # Last bump in 2005, does not build against current
 # stable net-nds/openldap-2.4.19-r1 bug #247956
 # Removal in 30 days
 net-dns/ldapdns
 

So what about http://www.gentoo.org/doc/en/ldapdns-guide.xml -- you want the 
GDP to just remove the doc? We can do that.

Is there a compatible drop-in replacement that will allow us to s/ldapdns/foo 
throughout the guide?


signature.asc
Description: PGP signature


Re: [gentoo-dev] Election for the Gentoo Council empty seat

2009-12-25 Thread Tobias Scherbaum
Am Dienstag, den 15.12.2009, 23:36 -0100 schrieb Jorge Manuel B. S.
Vicetto:
 nomination: December 17th to 30th

I'd like to nominate dev-zero.

- Tobias

-- 
Praxisbuch Nagios
http://www.oreilly.de/catalog/pbnagiosger/

https://www.xing.com/profile/Tobias_Scherbaum


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil


Re: [gentoo-dev] QA last rites for media-gfx/viewer

2009-12-25 Thread James Cloos
 Diego == Diego E Pettenò flamee...@gmail.com writes:

Diego # Fails to build if /usr/X11R6 is not present (bug #247737,

A bit trivial of an issue to drop a package, ja?

The QA team should generate more patches and fewer kills.

-JimC
-- 
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6



Re: [gentoo-dev] QA last rites for media-gfx/viewer

2009-12-25 Thread Samuli Suominen
On 12/25/2009 09:43 PM, James Cloos wrote:
 Diego == Diego E Pettenò flamee...@gmail.com writes:
 
 Diego # Fails to build if /usr/X11R6 is not present (bug #247737,
 
 A bit trivial of an issue to drop a package, ja?
 
 The QA team should generate more patches and fewer kills.

Manpower. Feel free to join up and help. A handful of people can't fix
everything. If it's broken, it shouldn't be in tree, simple as that.

-Samuli



Re: [gentoo-dev] QA last rites for media-gfx/viewer

2009-12-25 Thread Jeremy Olexa

James Cloos wrote:

Diego == Diego E Petten� flamee...@gmail.com writes:


Diego # Fails to build if /usr/X11R6 is not present (bug #247737,

A bit trivial of an issue to drop a package, ja?

The QA team should generate more patches and fewer kills.

-JimC


Also, where is the removal notice on bugzilla? I was going to create a 
version bump bug that blocked the removal bug but it didn't exist. In 
this case, not only did the QA team not create a (seemingly trivial) 
patch, but they didn't even follow standard package removal protocol.


-Jeremy



Re: [gentoo-dev] QA last rites for media-gfx/viewer

2009-12-25 Thread Petteri Räty
On 12/25/2009 10:41 PM, Jeremy Olexa wrote:
 James Cloos wrote:
 Diego == Diego E Petten� flamee...@gmail.com writes:

 Diego # Fails to build if /usr/X11R6 is not present (bug #247737,

 A bit trivial of an issue to drop a package, ja?

 The QA team should generate more patches and fewer kills.

 -JimC
 
 Also, where is the removal notice on bugzilla? I was going to create a
 version bump bug that blocked the removal bug but it didn't exist. In
 this case, not only did the QA team not create a (seemingly trivial)
 patch, but they didn't even follow standard package removal protocol.
 
 -Jeremy
 

Standard package removal protocol doesn't mandate opening a removal bug.
Treecleaner policy may but that's specific to them.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: [gentoo-dev-announce] January 2010 meeting date

2009-12-25 Thread Doug Goldstein
On Fri, Dec 25, 2009 at 8:00 AM, Thomas Sachau to...@gentoo.org wrote:
 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 

Re: [gentoo-dev] Last rites for net-dns/ldapdns

2009-12-25 Thread Victor Ostorga
On Fri, 25 Dec 2009 07:00:22 -0800
Joshua Saddler nightmo...@gentoo.org wrote:

 On Wed, 23 Dec 2009 10:40:06 -0600
 Victor Ostorga vosto...@gentoo.org wrote:
 
  
  # Víctor Ostorga vosto...@gentoo.org (23 Dec 2009)
  # Last bump in 2005, does not build against current
  # stable net-nds/openldap-2.4.19-r1 bug #247956
  # Removal in 30 days
  net-dns/ldapdns
  
 
 So what about http://www.gentoo.org/doc/en/ldapdns-guide.xml -- you
 want the GDP to just remove the doc? We can do that.
 
Yes, it will be needed to remove the doc.

 Is there a compatible drop-in replacement that will allow us to
 s/ldapdns/foo throughout the guide?

Unfortunately, I don't know an exact replacemente for ldapdns, at some
point I heard about a LDAP sdb back-end for BIND 9 [1], but don't know
if it is still functional.

[1] http://bind9-ldap.bayour.com/

Regards,

Víctor


signature.asc
Description: PGP signature