[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml

[Jeremy Olexa]

On 03/26/2011 12:52 AM, Mike Frysinger (vapier) wrote:

> Index: metadata.xml
> ===================================================================
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE pkgmetadata SYSTEM "http://www.gentoo.org/dtd/metadata.dtd">
> <pkgmetadata>
> <herd>no-herd</herd>
> <maintainer>
>    <email>maintainer-needed@gentoo.org</email>
> </maintainer>
> </pkgmetadata>

Can this practice of adding m-n packages to gentoo-x86 be stopped? If 
you add it, take responsibility for it, please. If you don't want to 
take responsibility for it, at least find a team that is willing to look 
after it.

Thanks,
-Jeremy

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml

[Nirbheek Chauhan]

On Sun, Mar 27, 2011 at 10:15 AM, Jeremy Olexa <darkside@gentoo.org> wrote:
> On 03/26/2011 12:52 AM, Mike Frysinger (vapier) wrote:
>
>> Index: metadata.xml
>> ===================================================================
>> <?xml version="1.0" encoding="UTF-8"?>
>> <!DOCTYPE pkgmetadata SYSTEM "http://www.gentoo.org/dtd/metadata.dtd">
>> <pkgmetadata>
>> <herd>no-herd</herd>
>> <maintainer>
>>   <email>maintainer-needed@gentoo.org</email>
>> </maintainer>
>> </pkgmetadata>
>
> Can this practice of adding m-n packages to gentoo-x86 be stopped? If you
> add it, take responsibility for it, please. If you don't want to take
> responsibility for it, at least find a team that is willing to look after
> it.
>

If you prohibit people from doing that, they'll just commit it
normally, and then remove themselves a week later.

I propose that we should be more aggressive about package.masking (for
removal) all maintainer-needed packages from the tree by doing that
one month after they become maintainer-needed. If someone doesn't
volunteer to take care of it, it probably wasn't important anyway.

-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml

[Markos Chandras]

[-- Attachment #1: Type: text/plain, Size: 1533 bytes --]

On Sun, Mar 27, 2011 at 01:17:46PM +0530, Nirbheek Chauhan wrote:
> On Sun, Mar 27, 2011 at 10:15 AM, Jeremy Olexa <darkside@gentoo.org> wrote:
> > On 03/26/2011 12:52 AM, Mike Frysinger (vapier) wrote:
> >
> >> Index: metadata.xml
> >> ===================================================================
> >> <?xml version="1.0" encoding="UTF-8"?>
> >> <!DOCTYPE pkgmetadata SYSTEM "http://www.gentoo.org/dtd/metadata.dtd">
> >> <pkgmetadata>
> >> <herd>no-herd</herd>
> >> <maintainer>
> >>   <email>maintainer-needed@gentoo.org</email>
> >> </maintainer>
> >> </pkgmetadata>
> >
> > Can this practice of adding m-n packages to gentoo-x86 be stopped? If you
> > add it, take responsibility for it, please. If you don't want to take
> > responsibility for it, at least find a team that is willing to look after
> > it.
> >
> 
> If you prohibit people from doing that, they'll just commit it
> normally, and then remove themselves a week later.
> 
> I propose that we should be more aggressive about package.masking (for
> removal) all maintainer-needed packages from the tree by doing that
> one month after they become maintainer-needed. If someone doesn't
> volunteer to take care of it, it probably wasn't important anyway.
> 
> -- 
> ~Nirbheek Chauhan
> 
> Gentoo GNOME+Mozilla Team
> 
Uhm no. The fact that nobody takes care of it doesn't necessarily mean
that the package is broken and that it should be removed

Regards,
-- 
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml

[Nirbheek Chauhan]

On Sun, Mar 27, 2011 at 3:59 PM, Markos Chandras <hwoarang@gentoo.org> wrote:
> On Sun, Mar 27, 2011 at 01:17:46PM +0530, Nirbheek Chauhan wrote:
>> On Sun, Mar 27, 2011 at 10:15 AM, Jeremy Olexa <darkside@gentoo.org> wrote:
>> > Can this practice of adding m-n packages to gentoo-x86 be stopped? If you
>> > add it, take responsibility for it, please. If you don't want to take
>> > responsibility for it, at least find a team that is willing to look after
>> > it.
>> >
>>
>> If you prohibit people from doing that, they'll just commit it
>> normally, and then remove themselves a week later.
>>
>> I propose that we should be more aggressive about package.masking (for
>> removal) all maintainer-needed packages from the tree by doing that
>> one month after they become maintainer-needed. If someone doesn't
>> volunteer to take care of it, it probably wasn't important anyway.
>>
>>
> Uhm no. The fact that nobody takes care of it doesn't necessarily mean
> that the package is broken and that it should be removed
>

I never said that such packages were broken. I'm saying that if no one
wants to maintain them, they probably aren't needed by anyone, and we
should clean such cruft from the tree.

If they *are* needed by someone, then those folks should come forward
to maintain it.

-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

Treeclean all maintainer-needed packages, was: Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml

[Chí-Thanh Christopher Nguyễn]

Nirbheek Chauhan schrieb:
>>> I propose that we should be more aggressive about package.masking (for
>>> removal) all maintainer-needed packages from the tree by doing that
>>> one month after they become maintainer-needed. If someone doesn't
>>> volunteer to take care of it, it probably wasn't important anyway.
>>>
>>>
>> Uhm no. The fact that nobody takes care of it doesn't necessarily mean
>> that the package is broken and that it should be removed
>>
>
> I never said that such packages were broken. I'm saying that if no one
> wants to maintain them, they probably aren't needed by anyone, and we
> should clean such cruft from the tree.
>
> If they *are* needed by someone, then those folks should come forward
> to maintain it.
>

The only such package I would like to see go is net-misc/mDNSResponder. 
And I am not convinced that having a maintainer listed in metadata.xml 
makes the package automatically non-cruft, or that orphaned packages are 
not at all cared about.


Best regards,
Chí-Thanh Christopher Nguyễn

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 1448 bytes --]

On Sun, 27 Mar 2011 15:09:09 +0530
Nirbheek Chauhan <nirbheek@gentoo.org> wrote:

> On Sun, Mar 27, 2011 at 3:59 PM, Markos Chandras <hwoarang@gentoo.org> wrote:
> > On Sun, Mar 27, 2011 at 01:17:46PM +0530, Nirbheek Chauhan wrote:

> >> I propose that we should be more aggressive about package.masking (for
> >> removal) all maintainer-needed packages from the tree by doing that
> >> one month after they become maintainer-needed. If someone doesn't
> >> volunteer to take care of it, it probably wasn't important anyway.
> >>
> >>
> > Uhm no. The fact that nobody takes care of it doesn't necessarily mean
> > that the package is broken and that it should be removed
> >
> 
> I never said that such packages were broken. I'm saying that if no one
> wants to maintain them, they probably aren't needed by anyone, and we
> should clean such cruft from the tree.

This is just wrong.  If a package is working then it's easy to overlook the
fact it has no maintainer.  Nor does it need one.  When it breaks is when
people notice and either fix it or trash it.

> If they *are* needed by someone, then those folks should come forward
> to maintain it.

Good luck with that. :)


-- 
fonts, gcc-porting,                  it makes no sense how it makes no sense
toolchain, wxwidgets                           but i'll take it free anytime
@ gentoo.org                EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml

[Jeremy Olexa]

On 03/27/2011 02:47 AM, Nirbheek Chauhan wrote:
> On Sun, Mar 27, 2011 at 10:15 AM, Jeremy Olexa<darkside@gentoo.org>  wrote:
>> On 03/26/2011 12:52 AM, Mike Frysinger (vapier) wrote:
>>
>>> Index: metadata.xml
>>> ===================================================================
>>> <?xml version="1.0" encoding="UTF-8"?>
>>> <!DOCTYPE pkgmetadata SYSTEM "http://www.gentoo.org/dtd/metadata.dtd">
>>> <pkgmetadata>
>>> <herd>no-herd</herd>
>>> <maintainer>
>>>    <email>maintainer-needed@gentoo.org</email>
>>> </maintainer>
>>> </pkgmetadata>
>>
>> Can this practice of adding m-n packages to gentoo-x86 be stopped? If you
>> add it, take responsibility for it, please. If you don't want to take
>> responsibility for it, at least find a team that is willing to look after
>> it.
>>
>
> If you prohibit people from doing that, they'll just commit it
> normally, and then remove themselves a week later.

Why does anyone need to *add* a package that is maintainer-needed? This 
is one of the problems of the gentoo-x86 tree - too many 
maintainer-needed packages. It is a bad thing for our users because when 
they submit bugs and/or fixes, they go [generally] unnoticed for ages. 
Also, as you may know, the treecleaner team is constantly "fighting" 
with removing m-n packages.

The tree has 679 m-n packages. 
http://www.gentoo.org/proj/en/qa/treecleaners/maintainer-needed.xml

>
> I propose that we should be more aggressive about package.masking (for
> removal) all maintainer-needed packages from the tree by doing that
> one month after they become maintainer-needed. If someone doesn't
> volunteer to take care of it, it probably wasn't important anyway.
>

That is abit extreme for me (read: I don't have motivation to fight the 
flames), but I wouldn't complain if someone else did it to be honest.

-Jeremy

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml

[Nirbheek Chauhan]

On Sun, Mar 27, 2011 at 7:00 PM, Jeremy Olexa <darkside@gentoo.org> wrote:
> On 03/27/2011 02:47 AM, Nirbheek Chauhan wrote:
>> If you prohibit people from doing that, they'll just commit it
>> normally, and then remove themselves a week later.
>
> Why does anyone need to *add* a package that is maintainer-needed? This is
> one of the problems of the gentoo-x86 tree - too many maintainer-needed
> packages.

I'm just pointing out that if you prohibit that by policy, this is
what people will do. The real problem is that maintainer-needed
packages are allowed to remain in the tree *indefinitely*.

>> I propose that we should be more aggressive about package.masking (for
>> removal) all maintainer-needed packages from the tree by doing that
>> one month after they become maintainer-needed. If someone doesn't
>> volunteer to take care of it, it probably wasn't important anyway.
>>
>
> That is abit extreme for me (read: I don't have motivation to fight the
> flames), but I wouldn't complain if someone else did it to be honest.
>

Just start removing old[1] maintainer-needed packages. If people
complain, tell them to start maintaining it. If they continue to
complain, ignore them. As tree-cleaner, you have the power to do this
and not take bullshit from people about it.


1. Set old as one month, with a 2 month package.mask duration before
it's removed.
-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml

[Alec Warner]

On Sun, Mar 27, 2011 at 1:43 PM, Nirbheek Chauhan <nirbheek@gentoo.org> wrote:
> On Sun, Mar 27, 2011 at 7:00 PM, Jeremy Olexa <darkside@gentoo.org> wrote:
>> On 03/27/2011 02:47 AM, Nirbheek Chauhan wrote:
>>> If you prohibit people from doing that, they'll just commit it
>>> normally, and then remove themselves a week later.
>>
>> Why does anyone need to *add* a package that is maintainer-needed? This is
>> one of the problems of the gentoo-x86 tree - too many maintainer-needed
>> packages.
>
> I'm just pointing out that if you prohibit that by policy, this is
> what people will do. The real problem is that maintainer-needed
> packages are allowed to remain in the tree *indefinitely*.
>
>>> I propose that we should be more aggressive about package.masking (for
>>> removal) all maintainer-needed packages from the tree by doing that
>>> one month after they become maintainer-needed. If someone doesn't
>>> volunteer to take care of it, it probably wasn't important anyway.
>>>
>>
>> That is abit extreme for me (read: I don't have motivation to fight the
>> flames), but I wouldn't complain if someone else did it to be honest.
>>
>
> Just start removing old[1] maintainer-needed packages. If people
> complain, tell them to start maintaining it. If they continue to
> complain, ignore them. As tree-cleaner, you have the power to do this
> and not take bullshit from people about it.

The intent of the TreeCleaner project (years ago) was to essentially
look for packages in bugzilla that had lots of bugs and no maintainer.
 For a while beandog essentially maintained a site that tracked this
for us (Gentoo Package that need Lovin' was the awesome title.)

From that list you either fixed the problems and commited them (e.g.
you were a roving package maintainer) or you pmasked it and marked it
for the deadpool.

There is not much policy on treecleaning a package just because no one
has touched it.  Time since last touch was just one of a dozen
indicators used to find packages that are broken (because a package
not touched since 2006 is also not likely to compile.)

-A

>
>
> 1. Set old as one month, with a 2 month package.mask duration before
> it's removed.
> --
> ~Nirbheek Chauhan
>
> Gentoo GNOME+Mozilla Team
>
>

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml

[Nirbheek Chauhan]

On Mon, Mar 28, 2011 at 12:47 AM, Alec Warner <antarus@gentoo.org> wrote:
> On Sun, Mar 27, 2011 at 1:43 PM, Nirbheek Chauhan <nirbheek@gentoo.org> wrote:
>> Just start removing old[1] maintainer-needed packages. If people
>> complain, tell them to start maintaining it. If they continue to
>> complain, ignore them. As tree-cleaner, you have the power to do this
>> and not take bullshit from people about it.
>
> The intent of the TreeCleaner project (years ago) was to essentially
> look for packages in bugzilla that had lots of bugs and no maintainer.
>  For a while beandog essentially maintained a site that tracked this
> for us (Gentoo Package that need Lovin' was the awesome title.)
>
> From that list you either fixed the problems and commited them (e.g.
> you were a roving package maintainer) or you pmasked it and marked it
> for the deadpool.
>
> There is not much policy on treecleaning a package just because no one
> has touched it.  Time since last touch was just one of a dozen
> indicators used to find packages that are broken (because a package
> not touched since 2006 is also not likely to compile.)
>

Sure, that's the history. But what made sense back then doesn't make
sense now. Back then we didn't have 600+ packages that no one
maintains, and whose bugs go almost entirely unread. We had crazy
amounts of manpower back then.

As we evolve, the responsibilities of the different parts of Gentoo
also evolve. As such, the tree-cleaners project has evolved, and if
the team isn't allowed to clean the tree, then why do we even have it
anymore?

I really don't understand *why* people want to keep around
unmaintained packages. If a package is not maintained, we should come
up and say it outright. Trying to maintain the illusion of maintenance
is really bad — for each person reporting a bug about a package, 100
people who got that same bug don't report it at all. So what happens
when there are just 50 users for some packages? Half the time we won't
even know that one of them is broken[1]. The rest of the time, users
will get a bad impression of Gentoo saying "Man, half the packages
don't even work".

It's really simple:

(a) If the package has plenty of users, there should be no problems
finding a maintainer or a proxy-maintainer.
(b) If the package has few users and is high-maintenance, it's either
already broken, or will get broken soon without a maintainer. Find one
or remove it!
(c) If the package has few users and is low-maintenance, package.mask
it so we can figure out who the users are, and we can get them to
proxy-maintain it, it's so little work anyway, right?
(d) If the package has very few or no users, what the hell is it doing
unmaintained in the tree? It's just eating up disk inodes and space.

We all like to boast about how gentoo has 15,000 packages, but we
neglect to mention that more than 1000 of these are either
unmaintained or very poorly maintained. And this is a very
conservative number.

Let's not turn portage into a graveyard for packages. Let's just remove crap.

1. Writer is bad at statistics, this is probably inaccurate.

-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml

[Alec Warner]

On Sun, Mar 27, 2011 at 7:40 PM, Nirbheek Chauhan <nirbheek@gentoo.org> wrote:
> On Mon, Mar 28, 2011 at 12:47 AM, Alec Warner <antarus@gentoo.org> wrote:
>> On Sun, Mar 27, 2011 at 1:43 PM, Nirbheek Chauhan <nirbheek@gentoo.org> wrote:
>>> Just start removing old[1] maintainer-needed packages. If people
>>> complain, tell them to start maintaining it. If they continue to
>>> complain, ignore them. As tree-cleaner, you have the power to do this
>>> and not take bullshit from people about it.
>>
>> The intent of the TreeCleaner project (years ago) was to essentially
>> look for packages in bugzilla that had lots of bugs and no maintainer.
>>  For a while beandog essentially maintained a site that tracked this
>> for us (Gentoo Package that need Lovin' was the awesome title.)
>>
>> From that list you either fixed the problems and commited them (e.g.
>> you were a roving package maintainer) or you pmasked it and marked it
>> for the deadpool.
>>
>> There is not much policy on treecleaning a package just because no one
>> has touched it.  Time since last touch was just one of a dozen
>> indicators used to find packages that are broken (because a package
>> not touched since 2006 is also not likely to compile.)
>>
>
> Sure, that's the history. But what made sense back then doesn't make
> sense now. Back then we didn't have 600+ packages that no one
> maintains, and whose bugs go almost entirely unread. We had crazy
> amounts of manpower back then.

We probably had more than 600 unmaintained packages because no one was
removing dead packages from the tree.  I also dispute your manpower
logic.  Gentoo has been short on developers for years.  I don't see
how 2011 is any different than 2007 in this aspect.

>
> As we evolve, the responsibilities of the different parts of Gentoo
> also evolve. As such, the tree-cleaners project has evolved, and if
> the team isn't allowed to clean the tree, then why do we even have it
> anymore?

The community got pissed when I deleted unmaintained packages from the
tree 'just because it was unmaintained.'  Thats why there were a set
of criteria for removal.  Maybe they changed their mind and you can
convince them.  Ignoring people's opinions because they are whiners
and you are Treecleaners is a thin edge to walk though; so I'd be
careful.  At least during my tenure there were still hundreds of
unmaintained and broken packages; so I didn't much care about
unmaintained but working stuff (since there was plenty of work to do.)
 I would argue the tree is still in a similar state.

>
> I really don't understand *why* people want to keep around
> unmaintained packages. If a package is not maintained, we should come
> up and say it outright. Trying to maintain the illusion of maintenance
> is really bad — for each person reporting a bug about a package, 100
> people who got that same bug don't report it at all. So what happens
> when there are just 50 users for some packages? Half the time we won't
> even know that one of them is broken[1]. The rest of the time, users
> will get a bad impression of Gentoo saying "Man, half the packages
> don't even work".

Properly tagged I don't think there is any illusion.
Maintainer-needed is maintainer-needed after all.  If half of the
packages *in the tree* don't work then we have a problem.  If half the
packages *a user tries to install* are broken then they should
certainly use another distro.  Perhaps Gentoo is not for their area
(and the key point is that it doesn't have to be.)

>
> It's really simple:
>
> (a) If the package has plenty of users, there should be no problems
> finding a maintainer or a proxy-maintainer.
> (b) If the package has few users and is high-maintenance, it's either
> already broken, or will get broken soon without a maintainer. Find one
> or remove it!
> (c) If the package has few users and is low-maintenance, package.mask
> it so we can figure out who the users are, and we can get them to
> proxy-maintain it, it's so little work anyway, right?
> (d) If the package has very few or no users, what the hell is it doing
> unmaintained in the tree? It's just eating up disk inodes and space.

So launch gstats and get usage numbers.  If no one is using a package
that is a keen indicator it can be punted; however no one will get off
their ass and get more data to back anything up (myself included...)
All of your points above assume we have a decent metric of 'how many
users a package has' and about the only way we know that is when users
file bugs for it (version bump, bug, feature req, etc..)

>
> We all like to boast about how gentoo has 15,000 packages, but we
> neglect to mention that more than 1000 of these are either
> unmaintained or very poorly maintained. And this is a very
> conservative number.

But again this is all made up...m-n was 670-odd packages last I
checked.  Do we still have m-w these days?

>
> Let's not turn portage into a graveyard for packages. Let's just remove crap.
>
> 1. Writer is bad at statistics, this is probably inaccurate.
>
> --
> ~Nirbheek Chauhan
>
> Gentoo GNOME+Mozilla Team
>
>

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml

[Nirbheek Chauhan]

On Mon, Mar 28, 2011 at 1:47 AM, Alec Warner <antarus@gentoo.org> wrote:
> On Sun, Mar 27, 2011 at 7:40 PM, Nirbheek Chauhan <nirbheek@gentoo.org> wrote:
>> Sure, that's the history. But what made sense back then doesn't make
>> sense now. Back then we didn't have 600+ packages that no one
>> maintains, and whose bugs go almost entirely unread. We had crazy
>> amounts of manpower back then.
>
> We probably had more than 600 unmaintained packages because no one was
> removing dead packages from the tree.  I also dispute your manpower
> logic.  Gentoo has been short on developers for years.  I don't see
> how 2011 is any different than 2007 in this aspect.
>

The current problem is burnt-out or semi-active devs who commit
occasionally, but aren't able to help with any herd-related work
because they're out of touch. As such, their presence in the team
gives a false indication of strength. This problem was much less
severe in 2007 (afair).

>>
>> As we evolve, the responsibilities of the different parts of Gentoo
>> also evolve. As such, the tree-cleaners project has evolved, and if
>> the team isn't allowed to clean the tree, then why do we even have it
>> anymore?
>
> The community got pissed when I deleted unmaintained packages from the
> tree 'just because it was unmaintained.'  Thats why there were a set
> of criteria for removal.  Maybe they changed their mind and you can
> convince them.

Well, I bet that more than half of them retired or stopped being active.

> Ignoring people's opinions because they are whiners
> and you are Treecleaners is a thin edge to walk though; so I'd be
> careful.


> At least during my tenure there were still hundreds of
> unmaintained and broken packages; so I didn't much care about
> unmaintained but working stuff (since there was plenty of work to do.)
>  I would argue the tree is still in a similar state.
>

The fun part is that we really don't even know in what state those
packages are w.r.t. runtime issues. I know that deigo's tinderbox
keeps track of compile-time issues *extremely* well, but we have zero
runtime testing.


>> I really don't understand *why* people want to keep around
>> unmaintained packages. If a package is not maintained, we should come
>> up and say it outright. Trying to maintain the illusion of maintenance
>> is really bad — for each person reporting a bug about a package, 100
>> people who got that same bug don't report it at all. So what happens
>> when there are just 50 users for some packages? Half the time we won't
>> even know that one of them is broken[1]. The rest of the time, users
>> will get a bad impression of Gentoo saying "Man, half the packages
>> don't even work".
>
> Properly tagged I don't think there is any illusion.
> Maintainer-needed is maintainer-needed after all.

The problem is that from the PoV of the user, everything in the tree
is "official". After all, that's how all the distros function.

> So launch gstats and get usage numbers.  If no one is using a package
> that is a keen indicator it can be punted; however no one will get off
> their ass and get more data to back anything up (myself included...)

If we launch gstats *today*, it'll take us at least a long time before
we get decent numbers, and even after that, those numbers will be
biased towards those people who are really active in following Gentoo
news and developments. Unlike Firefox's usage stats, we have no way of
prompting pre-existing gentoo installations with a "Do want to take
part in gstats?" question.

> All of your points above assume we have a decent metric of 'how many
> users a package has' and about the only way we know that is when users
> file bugs for it (version bump, bug, feature req, etc..)
>

Yes. But we have another (more reliable) way: p.mask it and wait for
people to complain.

>>
>> We all like to boast about how gentoo has 15,000 packages, but we
>> neglect to mention that more than 1000 of these are either
>> unmaintained or very poorly maintained. And this is a very
>> conservative number.
>
> But again this is all made up...m-n was 670-odd packages last I
> checked.  Do we still have m-w these days?
>

"very poorly" meant "maintainers ignoring bugs for years", or empty
herds. We have plenty of both.

-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 4529 bytes --]

On Mon, 28 Mar 2011 02:55:14 +0530
Nirbheek Chauhan <nirbheek@gentoo.org> wrote:

> The current problem is burnt-out or semi-active devs who commit
> occasionally, but aren't able to help with any herd-related work
> because they're out of touch. As such, their presence in the team
> gives a false indication of strength. This problem was much less
> severe in 2007 (afair).

What?  If anything it was much worse. It used to be next to impossible to get
any answer whatsoever out of some herds until you gave up and fixed it
yourself.  Then they would bitch you out for touching their junk.  My job has
gotten a lot easier lately.

> > The community got pissed when I deleted unmaintained packages from the
> > tree 'just because it was unmaintained.'  Thats why there were a set
> > of criteria for removal.  Maybe they changed their mind and you can
> > convince them.
> 
> Well, I bet that more than half of them retired or stopped being active.

Nope, still here, still bitching. :)

> > At least during my tenure there were still hundreds of
> > unmaintained and broken packages; so I didn't much care about
> > unmaintained but working stuff (since there was plenty of work to do.)
> >  I would argue the tree is still in a similar state.
> 
> The fun part is that we really don't even know in what state those
> packages are w.r.t. runtime issues. I know that deigo's tinderbox
> keeps track of compile-time issues *extremely* well, but we have zero
> runtime testing.

Well, that /is/ what bugzilla is for, after all.  We can only fix what we
know is broken.  And I don't see how that's any different than "maintained"
packages.

> >> I really don't understand *why* people want to keep around
> >> unmaintained packages. If a package is not maintained, we should come
> >> up and say it outright. Trying to maintain the illusion of maintenance
> >> is really bad — for each person reporting a bug about a package, 100
> >> people who got that same bug don't report it at all. So what happens
> >> when there are just 50 users for some packages? Half the time we won't
> >> even know that one of them is broken[1]. The rest of the time, users
> >> will get a bad impression of Gentoo saying "Man, half the packages
> >> don't even work".
> >
> > Properly tagged I don't think there is any illusion.
> > Maintainer-needed is maintainer-needed after all.
> 
> The problem is that from the PoV of the user, everything in the tree
> is "official". After all, that's how all the distros function.

The problem is that you assume that anything that is maintainer-needed is
automatically broken, when the vast majority of it is not.  Would it make you
feel better if packages had default herds they could fall back on rather than
go maintainer-needed (eg. app-crypt packages would automatically go into the
crypto herd, media-gfx go to graphics, etc.)?  That's something we could be
more aggressive about.

> > So launch gstats and get usage numbers.  If no one is using a package
> > that is a keen indicator it can be punted; however no one will get off
> > their ass and get more data to back anything up (myself included...)
> 
> If we launch gstats *today*, it'll take us at least a long time before
> we get decent numbers, and even after that, those numbers will be
> biased towards those people who are really active in following Gentoo
> news and developments. Unlike Firefox's usage stats, we have no way of
> prompting pre-existing gentoo installations with a "Do want to take
> part in gstats?" question.

Last I checked we had a nifty news system for making announcements.  And I
thought we were supposed to have Smolt support like two years ago.  What
happened to it?

> > All of your points above assume we have a decent metric of 'how many
> > users a package has' and about the only way we know that is when users
> > file bugs for it (version bump, bug, feature req, etc..)
> 
> Yes. But we have another (more reliable) way: p.mask it and wait for
> people to complain.

Hey, maybe next we can slip random build errors into packages and see who
files bugs.  I don't know why people continue to think that breaking the
tree to see who complains is an acceptable form of QA.


-- 
fonts, gcc-porting,                  it makes no sense how it makes no sense
toolchain, wxwidgets                           but i'll take it free anytime
@ gentoo.org                EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 999 bytes --]

On 17:34 Sun 27 Mar     , Ryan Hill wrote:
> On Mon, 28 Mar 2011 02:55:14 +0530
> Nirbheek Chauhan <nirbheek@gentoo.org> wrote:
> > If we launch gstats *today*, it'll take us at least a long time before
> > we get decent numbers, and even after that, those numbers will be
> > biased towards those people who are really active in following Gentoo
> > news and developments. Unlike Firefox's usage stats, we have no way of
> > prompting pre-existing gentoo installations with a "Do want to take
> > part in gstats?" question.
> 
> Last I checked we had a nifty news system for making announcements.  And I
> thought we were supposed to have Smolt support like two years ago.  What
> happened to it?

I wonder the same question too, since it seems statistics is an 
eternally returning GSoC project.

Sebastian, you worked on this in 2009. What needs to happen to get it 
deployed?

-- 
Thanks,
Donnie

Donnie Berkholz
Sr. Developer, Gentoo Linux
Blog: http://dberkholz.com

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml

[Rich Freeman]

On Sun, Mar 27, 2011 at 3:40 PM, Nirbheek Chauhan <nirbheek@gentoo.org> wrote:
> It's really simple:
>
> (a) If the package has plenty of users, there should be no problems
> finding a maintainer or a proxy-maintainer.

Uh, I guess that's why we are flooded with people wanting to be
devs...  There are lots of high-use packages that could use more
maintainers.  I'm not aware of any teams that would turn away help.

> (b) If the package has few users and is high-maintenance, it's either
> already broken, or will get broken soon without a maintainer. Find one
> or remove it!

If it doesn't build, then it can be removed.  Nobody is arguing with
that.  If you think that someday it might not build, then just wait a
few months and if you're right you can satisfy your itch to prune the
tree...

> (c) If the package has few users and is low-maintenance, package.mask
> it so we can figure out who the users are, and we can get them to
> proxy-maintain it, it's so little work anyway, right?

Uh, package.mask is not intended to be an end-user communication tool.
 News is slightly better in this respect, but again this is not its
purpose.

We shouldn't be punishing people for not becoming developers.  I don't
want to use a distro that throws up warning messages every few months
because some package I've been using had its developer retire, and I'm
a developer.  If it breaks and I care enough about it, I'll rescue it.
 If I'm passionate about it, I'll step in before it breaks.  Holding
users ransom is not the solution.

> (d) If the package has very few or no users, what the hell is it doing
> unmaintained in the tree? It's just eating up disk inodes and space.
>

Uh, and how much does the inodes, space, and bandwidth consumed by
those ~700 m-n packages actually cost.  Are we talking about going
through wailing and gnashing of teeth so that our stakeholders can
save a total of 45 cents worth of disk space across 50 mirrors and
50,000 Gentoo boxes over the next 5 years?  If one person is getting
use out of it, and nobody is getting hurt, and it costs a few inodes,
I'm fine with that.

> We all like to boast about how gentoo has 15,000 packages, but we
> neglect to mention that more than 1000 of these are either
> unmaintained or very poorly maintained. And this is a very
> conservative number.

I don't know anybody who uses Gentoo because of our huge repository.
Sure, compared to LFS it is big.  Compared to most major distros,
Gentoo isn't all that large.  If all somebody wants is a ton of
packages they're going to run Debian or whatever.  Sure, we have a
nice repository and we should be proud of it, but I don't think
anybody is trying to over-inflate our repo size just by loading it up
with junk.

The thing I don't understand here is that there seems to be some
perception that having stuff in the tree or in Bugzilla costs us
something.  Sure, at some level it does, and if 99.99% of portage were
junk data, then we might have a problem.  However, database records
and inodes come billions for the dollar.  Having a few percent more
churn so that we can more gracefully handle the lifecycle of packages
doesn't seem like much of a sacrifice.  If you're tired of looking at
junk when you search bugzilla, then you need to think about how you're
searching it.  These sorts of arguments come up at work all the time
and unless there is some kind of regulatory issue at stake or real
loss of revenue associated with lost opportunities, chasing down
unnecessary database records to be "tidy" almost always costs far more
than it saves.

I'd be shocked if the total cost to our sponsors in mirror space for
m-n packages exceeded the value of time spent by everybody reading
this thread.  I think we should be practical - I'm all for giving
treecleaners a free hand when packages really cause problems, but
being anal-retentive just for the sake of doing so doesn't seem to
create real value.

Rich

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml

[Nirbheek Chauhan]

On Mon, Mar 28, 2011 at 2:14 AM, Rich Freeman <rich0@gentoo.org> wrote:
> On Sun, Mar 27, 2011 at 3:40 PM, Nirbheek Chauhan <nirbheek@gentoo.org> wrote:
>> It's really simple:
>>
>> (a) If the package has plenty of users, there should be no problems
>> finding a maintainer or a proxy-maintainer.
>
> Uh, I guess that's why we are flooded with people wanting to be
> devs...  There are lots of high-use packages that could use more
> maintainers.  I'm not aware of any teams that would turn away help.
>

Everyone thinks all is dandy, and so no one volunteers. Why would
someone volunteer their help if we don't advertise the need? Every
single team I know has members that are there for historical value and
don't do anything anymore. This means team member lists are inevitably
artificially inflated.

>> (b) If the package has few users and is high-maintenance, it's either
>> already broken, or will get broken soon without a maintainer. Find one
>> or remove it!
>
> If it doesn't build, then it can be removed.  Nobody is arguing with
> that.  If you think that someday it might not build, then just wait a
> few months and if you're right you can satisfy your itch to prune the
> tree...
>

I think you missed my point about fewer users meaning the likelihood
of bugs getting reported being low. And even if bugs get reported, who
reads bug reports assigned to maintainer-needed@gentoo.org?

>> (c) If the package has few users and is low-maintenance, package.mask
>> it so we can figure out who the users are, and we can get them to
>> proxy-maintain it, it's so little work anyway, right?
>
> Uh, package.mask is not intended to be an end-user communication tool.
>  News is slightly better in this respect, but again this is not its
> purpose.
>

End-user? No. Potential developer? Yes. That's why we have a one-month
package.mask period while last-riting unmaintained packages for QA
problems.

> We shouldn't be punishing people for not becoming developers.  I don't
> want to use a distro that throws up warning messages every few months
> because some package I've been using had its developer retire, and I'm
> a developer.  If it breaks and I care enough about it, I'll rescue it.
>  If I'm passionate about it, I'll step in before it breaks.  Holding
> users ransom is not the solution.
>

So you're worried that the "oldness" criteria in the policy should not
be too strict? Cool, that's something for discussion.

>> (d) If the package has very few or no users, what the hell is it doing
>> unmaintained in the tree? It's just eating up disk inodes and space.
>>
>
> Uh, and how much does the inodes, space, and bandwidth consumed by
> those ~700 m-n packages actually cost.  Are we talking about going
> through wailing and gnashing of teeth so that our stakeholders can
> save a total of 45 cents worth of disk space across 50 mirrors and
> 50,000 Gentoo boxes over the next 5 years?  If one person is getting
> use out of it, and nobody is getting hurt, and it costs a few inodes,
> I'm fine with that.
>

One person who gets some use out of it, and how many who either can't
compile it, or can't run it? This kind of thing affects how people see
Gentoo. Besides, removal of a package from the tree doesn't mean
there's no way to use it anymore. For those who still use that one
package that no one else really uses anymore, local portdir_overlay
configuration is really easy.

>> We all like to boast about how gentoo has 15,000 packages, but we
>> neglect to mention that more than 1000 of these are either
>> unmaintained or very poorly maintained. And this is a very
>> conservative number.
>
> I don't know anybody who uses Gentoo because of our huge repository.
> Sure, compared to LFS it is big.  Compared to most major distros,
> Gentoo isn't all that large.  If all somebody wants is a ton of
> packages they're going to run Debian or whatever.

Note that most other distros have large package numbers because they
split their packages into "pkgname", "pkgname-dev" "pkgname-doc", etc.
I'm not sure if anyone counts source-package numbers for binary
distros.

>  Sure, we have a
> nice repository and we should be proud of it, but I don't think
> anybody is trying to over-inflate our repo size just by loading it up
> with junk.
>
> The thing I don't understand here is that there seems to be some
> perception that having stuff in the tree or in Bugzilla costs us
> something.  Sure, at some level it does, and if 99.99% of portage were
> junk data, then we might have a problem.  However, database records
> and inodes come billions for the dollar.  Having a few percent more
> churn so that we can more gracefully handle the lifecycle of packages
> doesn't seem like much of a sacrifice.  If you're tired of looking at
> junk when you search bugzilla, then you need to think about how you're
> searching it.  These sorts of arguments come up at work all the time
> and unless there is some kind of regulatory issue at stake or real
> loss of revenue associated with lost opportunities, chasing down
> unnecessary database records to be "tidy" almost always costs far more
> than it saves.
>
> I'd be shocked if the total cost to our sponsors in mirror space for
> m-n packages exceeded the value of time spent by everybody reading
> this thread.  I think we should be practical - I'm all for giving
> treecleaners a free hand when packages really cause problems, but
> being anal-retentive just for the sake of doing so doesn't seem to
> create real value.
>

Where did this come from? My entire argument was based around the fact
that unmaintained packages that may or may not be broken fundamentally
constitute a *bad* experience for the user. If we cannot guarantee
that bugs for a package will be fixed, we should not take up the
responsibility of the package!

Which is worse? Suddenly pulling a package from underneath the feet of
users when it inevitably breaks or telling them upfront that it's
*completely not* supported by us so they can do something about it
before it breaks?


-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 1240 bytes --]

On 02:39 Mon 28 Mar     , Nirbheek Chauhan wrote:
> Where did this come from? My entire argument was based around the fact
> that unmaintained packages that may or may not be broken fundamentally
> constitute a *bad* experience for the user. If we cannot guarantee
> that bugs for a package will be fixed, we should not take up the
> responsibility of the package!
> 
> Which is worse? Suddenly pulling a package from underneath the feet of
> users when it inevitably breaks or telling them upfront that it's
> *completely not* supported by us so they can do something about it
> before it breaks?

Here's the key point: "may or may not." Arbitrary criteria with no 
relevance to whether a package works for users are not helpful.

The mere existence of a maintainer-needed package doesn't mean it should 
be removed. The existence of the same thing with numerous serious, 
unfixed bugs or tinderbox errors means something much different.

We have the ability to do these kinds of intersections today, since our 
wonderful bug wranglers normally insert the $CAT/$PN into summaries and 
Diego has tinderbox bugs filed.

-- 
Thanks,
Donnie

Donnie Berkholz
Sr. Developer, Gentoo Linux
Blog: http://dberkholz.com

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml

[René 'Necoro' Neumann]

[-- Attachment #1: Type: text/plain, Size: 1722 bytes --]

Am 27.03.2011 22:44, schrieb Rich Freeman:
> We shouldn't be punishing people for not becoming developers.  I don't
> want to use a distro that throws up warning messages every few months
> because some package I've been using had its developer retire, and I'm
> a developer.  If it breaks and I care enough about it, I'll rescue it.
>  If I'm passionate about it, I'll step in before it breaks.  Holding
> users ransom is not the solution.

Well, but you need some way of communicate that certain packages are w/o
a proper maintainer. Why else should someone step up? I, for instance,
was quite surprised about the list of m-n packages and seeing that quite
some packages I use are on that list. I would never had a look at it
without this thread (or are users nowadays supposed to check
metadata.xml on a regular basis?).

So, why not at least add some elog-like output at the end of an emerge
run like "The following installed packages are without maintainer:
$LIST. If you want to step up, please see $PROXY_MAINTAINER_URL."

And before you state "well - it is enough if someone steps up when it
breaks": Even then it might get unnoticed, that the package is
unmaintained. I never check thoroughly where the package gets assigned
to during bug-wrangling, and I suppose that I'm not alone here. So the
only thing one notices is a bug which never gets any response. And this
is frustrating.

Regarding the pro-active masking/removal: As a user I'd object to this.
Please try a less obtrusive path first, like the info output I mentioned
above. Seeing that used packages gets masked quite often spawns bad mood
(at least in my experience and seeing reactions in forum threads).

- René


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml

[Jeroen Roovers]

On Sun, 27 Mar 2011 23:28:05 +0200
René 'Necoro' Neumann <lists@necoro.eu> wrote:

> Am 27.03.2011 22:44, schrieb Rich Freeman:
> Well, but you need some way of communicate that certain packages are
> w/o a proper maintainer. Why else should someone step up? I, for
> instance, was quite surprised about the list of m-n packages and
> seeing that quite some packages I use are on that list. I would never
> had a look at it without this thread (or are users nowadays supposed
> to check metadata.xml on a regular basis?).

I remember distinctly that I once publicly proposed to change
<http://packages.gentoo.org/> to actually interpret packages'
<metadata.xml> and displaying its formatted contents on every
<http://packages.gentoo.org/package/CAT/PKG> page (notably because the
site mentioned and still mentions the last committer at the top of the
page, with his or her Gentoo e-mail alias/handle plainly visible, so at
the time I envisioned it to prevent people from addressing the
wrong developers). <metadata.xml> is a mere link on every page and
doesn't invite anyone to dig deeper, when it could be put to better
use. Our bugzilla database already has proper descriptions for every
alias we use, so we could reuse that information to improve
packages.g.o.

(Only, I cannot now find any trace of such a discussion at all, or even
the bug report I am quite certain I would have filed about this.)


     jer

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml

[Alec Warner]

On Mon, Apr 4, 2011 at 9:26 PM, Jeroen Roovers <jer@gentoo.org> wrote:
> On Sun, 27 Mar 2011 23:28:05 +0200
> René 'Necoro' Neumann <lists@necoro.eu> wrote:
>
>> Am 27.03.2011 22:44, schrieb Rich Freeman:
>> Well, but you need some way of communicate that certain packages are
>> w/o a proper maintainer. Why else should someone step up? I, for
>> instance, was quite surprised about the list of m-n packages and
>> seeing that quite some packages I use are on that list. I would never
>> had a look at it without this thread (or are users nowadays supposed
>> to check metadata.xml on a regular basis?).
>
> I remember distinctly that I once publicly proposed to change
> <http://packages.gentoo.org/> to actually interpret packages'
> <metadata.xml> and displaying its formatted contents on every
> <http://packages.gentoo.org/package/CAT/PKG> page (notably because the
> site mentioned and still mentions the last committer at the top of the
> page, with his or her Gentoo e-mail alias/handle plainly visible, so at
> the time I envisioned it to prevent people from addressing the
> wrong developers). <metadata.xml> is a mere link on every page and
> doesn't invite anyone to dig deeper, when it could be put to better
> use. Our bugzilla database already has proper descriptions for every
> alias we use, so we could reuse that information to improve
> packages.g.o.


http://www.gentoo.org/proj/en/qa/treecleaners/maintainer-needed.xml

?

>
> (Only, I cannot now find any trace of such a discussion at all, or even
> the bug report I am quite certain I would have filed about this.)
>
>
>     jer
>
>

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml

[Jeroen Roovers]

On Tue, 5 Apr 2011 03:58:05 -0700
Alec Warner <antarus@gentoo.org> wrote:

> http://www.gentoo.org/proj/en/qa/treecleaners/maintainer-needed.xml

People tend to visit <http://packages.gentoo.org/> when they find a
problem with a package, to find out more about the package, like who
maintains it. You wouldn't visit the URL above unless you already knew
about the maintenance status of a package.


     jer

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 458 bytes --]


> I remember distinctly that I once publicly proposed to change
> <http://packages.gentoo.org/> to actually interpret packages'
> <metadata.xml> and displaying its formatted contents on every
> <http://packages.gentoo.org/package/CAT/PKG> page 

Excellent idea, it would be great to have that on the packages.g.o site by default.

-- 
Andreas K. Huettel
Gentoo Linux developer - kde, sci, arm, tex
dilfridge@gentoo.org
http://www.akhuettel.de/

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml

[Rich Freeman]

On Sun, Mar 27, 2011 at 9:30 AM, Jeremy Olexa <darkside@gentoo.org> wrote:
> On 03/27/2011 02:47 AM, Nirbheek Chauhan wrote:
>>> On 03/26/2011 12:52 AM, Mike Frysinger (vapier) wrote:
>> I propose that we should be more aggressive about package.masking (for
>> removal) all maintainer-needed packages from the tree by doing that
>> one month after they become maintainer-needed. If someone doesn't
>> volunteer to take care of it, it probably wasn't important anyway.
>>
>
> That is abit extreme for me (read: I don't have motivation to fight the
> flames), but I wouldn't complain if someone else did it to be honest.
>

So, I'd like to propose that somewhere between adding stuff to the
tree that nobody has any intent to look after, and removing stuff that
has been around a long time with no clear problems, there is a happy
medium.

How about this - if you add a package to the tree, you are responsible
for it for at least a year.  If you can get somebody else to take it
then that is fine.  If it has problems QA can flame you (privately at
first) for it, and you should feel appropriately embarrassed and fix
it, or remove it.

After a year, it can go maintainer-needed.  Before a year, it cannot,
and you either need to actually maintain it, or remove it.  Developers
should not be adding packages they have no interest in whatsoever, or
that have so many QA issues initially that they're high-maintenance
right from the start.  If a dev gets a package from a proxy-maintainer
and they disappear then they can nurse it along or remove it as makes
sense - we should be nice to these devs but we shouldn't just cut the
packages loose.

Packages that are maintainer-needed stay around as long as they're not
making trouble.  If they get lots of complaints they get announced on
-dev, and after two weeks they get masked if not picked up.  If they
end up blocking something then likewise they get announced and then
masked.  That basically is the current practice anyway.

I don't see a need to remove m-n packages wholesale just to say that
we did it, or to punish users for not becoming devs or whatever.

And of course, the usual long-term solutions like making
proxy-maintaining easier should be pursued.

Rich

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml

[Tomáš Chvátal]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dne 27.3.2011 15:44, Rich Freeman napsal(a):
> On Sun, Mar 27, 2011 at 9:30 AM, Jeremy Olexa <darkside@gentoo.org> wrote:
>> On 03/27/2011 02:47 AM, Nirbheek Chauhan wrote:
>>>> On 03/26/2011 12:52 AM, Mike Frysinger (vapier) wrote:
>>> I propose that we should be more aggressive about package.masking (for
>>> removal) all maintainer-needed packages from the tree by doing that
>>> one month after they become maintainer-needed. If someone doesn't
>>> volunteer to take care of it, it probably wasn't important anyway.
>>>
>>
>> That is abit extreme for me (read: I don't have motivation to fight the
>> flames), but I wouldn't complain if someone else did it to be honest.
>>
> 
> So, I'd like to propose that somewhere between adding stuff to the
> tree that nobody has any intent to look after, and removing stuff that
> has been around a long time with no clear problems, there is a happy
> medium.
> 
> How about this - if you add a package to the tree, you are responsible
> for it for at least a year.  If you can get somebody else to take it
> then that is fine.  If it has problems QA can flame you (privately at
> first) for it, and you should feel appropriately embarrassed and fix
> it, or remove it.
> 
> After a year, it can go maintainer-needed.  Before a year, it cannot,
> and you either need to actually maintain it, or remove it.  Developers
> should not be adding packages they have no interest in whatsoever, or
> that have so many QA issues initially that they're high-maintenance
> right from the start.  If a dev gets a package from a proxy-maintainer
> and they disappear then they can nurse it along or remove it as makes
> sense - we should be nice to these devs but we shouldn't just cut the
> packages loose.
> 
> Packages that are maintainer-needed stay around as long as they're not
> making trouble.  If they get lots of complaints they get announced on
> -dev, and after two weeks they get masked if not picked up.  If they
> end up blocking something then likewise they get announced and then
> masked.  That basically is the current practice anyway.
> 
> I don't see a need to remove m-n packages wholesale just to say that
> we did it, or to punish users for not becoming devs or whatever.
> 
> And of course, the usual long-term solutions like making
> proxy-maintaining easier should be pursued.
> 
> Rich
> 
And how exactly you want to track the level of failure for the package?
Since nobody is watching them already we usually don't know how much
they fail until somebody tries to emerge them from dev team or notify QA
by adding as CC to bug...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2PT5MACgkQHB6c3gNBRYdepgCfYUo00PKNQFoa+ZaqGoPTHOuv
Dd8Ani+d1sa/jIHvrWyZrwOF3UUkESl8
=k1EI
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml

[Rich Freeman]

[-- Attachment #1: Type: text/plain, Size: 860 bytes --]

On Mar 27, 2011 11:01 AM, "Tomáš Chvátal" <scarabeus@gentoo.org> wrote:
> And how exactly you want to track the level of failure for the package?
> Since nobody is watching them already we usually don't know how much
> they fail until somebody tries to emerge them from dev team or notify QA
> by adding as CC to bug...

If a tree falls in the forest...does anybody care?

Broken packages that nobody notices don't cost us much. A tinderbox sweep
will id and tag them for cleaning eventually.

All I'm saying is that the problem is broken packages, so address those, m-n
or otherwise.

By all means be proactive about finding maintainers, but let's not go
purging working packages.

As far as how broken is too broken - if it causes the distro headaches,
address it. That could be blockers, or tons of bug reports, or whatever...

Rich

[-- Attachment #2: Type: text/html, Size: 1000 bytes --]

Maintainership offering; was: Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml

[René 'Necoro' Neumann]

[-- Attachment #1: Type: text/plain, Size: 481 bytes --]

Am 27.03.2011 15:30, schrieb Jeremy Olexa:
> The tree has 679 m-n packages.
> http://www.gentoo.org/proj/en/qa/treecleaners/maintainer-needed.xml

If you cannot find someone else as a maintainer and someone is willing
to proxy me, I'd take dev-vcs/stgit: I use it on a daily basis (though
only to manage my configs) and the current ebuild has been written by me
(well - except the -r1-Diff).

This would at least reduce the number of m-n packages to 678 :-)

- René


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: Maintainership offering; was: Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml

[Jeremy Olexa]

On 03/27/2011 09:08 AM, René 'Necoro' Neumann wrote:

> If you cannot find someone else as a maintainer and someone is willing
> to proxy me, I'd take dev-vcs/stgit: I use it on a daily basis (though


% cvs di
Index: metadata.xml
===================================================================
RCS file: /var/cvsroot/gentoo-x86/dev-vcs/stgit/metadata.xml,v
retrieving revision 1.1
diff -u -r1.1 metadata.xml
--- metadata.xml	6 Mar 2010 15:58:48 -0000	1.1
+++ metadata.xml	27 Mar 2011 18:56:24 -0000
@@ -3,6 +3,12 @@
  <pkgmetadata>
  <herd>no-herd</herd>
  <maintainer>
-  <email>maintainer-needed@gentoo.org</email>
+  <email>gentoo@necoro.eu</email>
+  <name>René 'Necoro' Neumann</name>
+  <description>Proxy maintainer, assign bugs</description>
+</maintainer>
+<maintainer>
+  <email>darkside@gentoo.org</email>
+  <description>Proxy committer, CC bugs</description>
  </maintainer>
  </pkgmetadata>

All yours, pleasure to work with you. Please maintain a relationship on 
relevant bugs and poke me via personal email when I forget to do 
something =D (By the way, I know nothing of this package and will rely 
on you to do the work minus committing, I'll do that for you)

-Jeremy

Proxy maintainership of app-misc/pwsafe, was Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml

[Christopher Head]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, 27 Mar 2011 08:30:16 -0500
Jeremy Olexa <darkside@gentoo.org> wrote:

> The tree has 679 m-n packages. 
> http://www.gentoo.org/proj/en/qa/treecleaners/maintainer-needed.xml

I want to proxy-maintain app-misc/pwsafe. It hasn't been updated in six
years, but it still builds (albeit with a few warnings) and works and I
use it and don't want to see it disappear. Is anyone willing to do this?

Chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: GnuPT 2.7.2

iEYEARECAAYFAk2PnAEACgkQXUF6hOTGP7fSvACgls+xMxexfWytiXxYH0VwTY9c
G1MAn3nKImR6inTrnh2Bsnq86rcsbzXd
=pDQ6
-----END PGP SIGNATURE-----

Re: Proxy maintainership of app-misc/pwsafe, was Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml

[Nirbheek Chauhan]

On Mon, Mar 28, 2011 at 1:50 AM, Christopher Head <headch@gmail.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Sun, 27 Mar 2011 08:30:16 -0500
> Jeremy Olexa <darkside@gentoo.org> wrote:
>
>> The tree has 679 m-n packages.
>> http://www.gentoo.org/proj/en/qa/treecleaners/maintainer-needed.xml
>
> I want to proxy-maintain app-misc/pwsafe. It hasn't been updated in six
> years, but it still builds (albeit with a few warnings) and works and I
> use it and don't want to see it disappear. Is anyone willing to do this?
>

I can proxy-maintain app-misc/pwsafe with you. I have no idea how
pwsafe works, though, so I'll trust that you've done your homework
w.r.t bumps or bugfixes :)

There are currently two bugs open with pwsafe:

https://bugs.gentoo.org/show_bug.cgi?id=347549 (stable req)
https://bugs.gentoo.org/show_bug.cgi?id=292749 (cosmetic enhancement)

You should open a bugzilla account so that I can assign these to you.
However, the bugs aren't urgent, so we can tackle them when you have
time.

--- metadata.xml	22 Mar 2009 02:35:03 -0000	1.5
+++ metadata.xml	27 Mar 2011 20:46:54 -0000
@@ -3,7 +3,13 @@
 <pkgmetadata>
   <herd>no-herd</herd>
   <maintainer>
-    <email>maintainer-needed@gentoo.org</email>
+	<name>Christopher Head</name>	
+	<email>headch@gentoo.org</email>
+	<description>Proxy maintainer, assign bugs</description>
+  </maintainer>
+  <maintainer>
+	<name>Nirbheek Chauhan</name>	
+    <email>nirbheek@gentoo.org</email>
   </maintainer>
   <longdescription lang="en">
     pwsafe is a commandline password database utility compatible with


-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

Re: Proxy maintainership of app-misc/pwsafe, was Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml

[René 'Necoro' Neumann]

[-- Attachment #1: Type: text/plain, Size: 415 bytes --]

Am 27.03.2011 22:47, schrieb Nirbheek Chauhan:
> --- metadata.xml	22 Mar 2009 02:35:03 -0000	1.5
> +++ metadata.xml	27 Mar 2011 20:46:54 -0000
> @@ -3,7 +3,13 @@
>  <pkgmetadata>
>    <herd>no-herd</herd>
>    <maintainer>
> -    <email>maintainer-needed@gentoo.org</email>
> +	<name>Christopher Head</name>	
> +	<email>headch@gentoo.org</email>

That should be s/gentoo.org/gmail.com/, shouldn't it?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: Proxy maintainership of app-misc/pwsafe, was Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml

[David Abbott]

On Sun, Mar 27, 2011 at 4:47 PM, Nirbheek Chauhan <nirbheek@gentoo.org> wrote:
> On Mon, Mar 28, 2011 at 1:50 AM, Christopher Head <headch@gmail.com> wrote:
>
> --- metadata.xml        22 Mar 2009 02:35:03 -0000      1.5
> +++ metadata.xml        27 Mar 2011 20:46:54 -0000
> @@ -3,7 +3,13 @@
>  <pkgmetadata>
>   <herd>no-herd</herd>
>   <maintainer>
> -    <email>maintainer-needed@gentoo.org</email>
> +       <name>Christopher Head</name>
> +       <email>headch@gentoo.org</email>
> +       <description>Proxy maintainer, assign bugs</description>
> +  </maintainer>
> +  <maintainer>
> +       <name>Nirbheek Chauhan</name>
> +    <email>nirbheek@gentoo.org</email>
>   </maintainer>
>   <longdescription lang="en">
>     pwsafe is a commandline password database utility compatible with
>
>
> --
> ~Nirbheek Chauhan
>
> Gentoo GNOME+Mozilla Team
>
>

 -  <email>headch@gentoo.org</email>
+ <email>headch@gmail.com</email>

-- 
David Abbott (dabbott)
Gentoo
http://dev.gentoo.org/~dabbott/

Re: Proxy maintainership of app-misc/pwsafe, was Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml

[Nirbheek Chauhan]

On Mon, Mar 28, 2011 at 2:25 AM, David Abbott <dabbott@gentoo.org> wrote:
> On Sun, Mar 27, 2011 at 4:47 PM, Nirbheek Chauhan <nirbheek@gentoo.org> wrote:
>> On Mon, Mar 28, 2011 at 1:50 AM, Christopher Head <headch@gmail.com> wrote:
>>
>> --- metadata.xml        22 Mar 2009 02:35:03 -0000      1.5
>> +++ metadata.xml        27 Mar 2011 20:46:54 -0000
>> @@ -3,7 +3,13 @@
>>  <pkgmetadata>
>>   <herd>no-herd</herd>
>>   <maintainer>
>> -    <email>maintainer-needed@gentoo.org</email>
>> +       <name>Christopher Head</name>
>> +       <email>headch@gentoo.org</email>
>> +       <description>Proxy maintainer, assign bugs</description>
>> +  </maintainer>
>> +  <maintainer>
>> +       <name>Nirbheek Chauhan</name>
>> +    <email>nirbheek@gentoo.org</email>
>>   </maintainer>
>>   <longdescription lang="en">
>>     pwsafe is a commandline password database utility compatible with
>>
>>
>> --
>> ~Nirbheek Chauhan
>>
>> Gentoo GNOME+Mozilla Team
>>
>>
>
>  -  <email>headch@gentoo.org</email>
> + <email>headch@gmail.com</email>
>

Oops, fixed :)


-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml

[Dirkjan Ochtman]

On Sun, Mar 27, 2011 at 15:30, Jeremy Olexa <darkside@gentoo.org> wrote:
> Why does anyone need to *add* a package that is maintainer-needed?

Regardless of how we might want to get rid of m-n packages, I do
wonder about who commits them, and why. For example, while looking
into the list of m-n packages, I also found
dev-python/remoteobjects-99999999, which was also entered into the
tree by vapier as m-n.

vapier, what's the rationale behind including these packages in the
tree? And if you need them, why can't you maintain them?

(I'm asking this as a member of the Python project, where we probably
wouldn't mind picking up some python m-n packages.)

Cheers,

Dirkjan

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml

[Jeroen Roovers]

On Sun, 27 Mar 2011 13:17:46 +0530
Nirbheek Chauhan <nirbheek@gentoo.org> wrote:

> I propose that we should be more aggressive about package.masking (for
> removal) all maintainer-needed packages from the tree by doing that
> one month after they become maintainer-needed. If someone doesn't
> volunteer to take care of it, it probably wasn't important anyway.

That would never work with m-n packages that other packages *DEPEND on.


     jer