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

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

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

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

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

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

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

-----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/

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

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

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