Gentoo Archives: gentoo-dev

From: Rich Freeman <rich0@g.o>
To: gentoo-dev@l.g.o
Cc: Jeremy Olexa <darkside@g.o>
Subject: Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml
Date: Sun, 27 Mar 2011 13:45:24
Message-Id: AANLkTikW=5z0ULH6ELC6qPe9QEdyUyDHVCwReLC9=TXM@mail.gmail.com
In Reply to: Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/PyZilla: PyZilla-0.1.0.ebuild ChangeLog metadata.xml by Jeremy Olexa
1 On Sun, Mar 27, 2011 at 9:30 AM, Jeremy Olexa <darkside@g.o> wrote:
2 > On 03/27/2011 02:47 AM, Nirbheek Chauhan wrote:
3 >>> On 03/26/2011 12:52 AM, Mike Frysinger (vapier) wrote:
4 >> I propose that we should be more aggressive about package.masking (for
5 >> removal) all maintainer-needed packages from the tree by doing that
6 >> one month after they become maintainer-needed. If someone doesn't
7 >> volunteer to take care of it, it probably wasn't important anyway.
8 >>
9 >
10 > That is abit extreme for me (read: I don't have motivation to fight the
11 > flames), but I wouldn't complain if someone else did it to be honest.
12 >
13
14 So, I'd like to propose that somewhere between adding stuff to the
15 tree that nobody has any intent to look after, and removing stuff that
16 has been around a long time with no clear problems, there is a happy
17 medium.
18
19 How about this - if you add a package to the tree, you are responsible
20 for it for at least a year. If you can get somebody else to take it
21 then that is fine. If it has problems QA can flame you (privately at
22 first) for it, and you should feel appropriately embarrassed and fix
23 it, or remove it.
24
25 After a year, it can go maintainer-needed. Before a year, it cannot,
26 and you either need to actually maintain it, or remove it. Developers
27 should not be adding packages they have no interest in whatsoever, or
28 that have so many QA issues initially that they're high-maintenance
29 right from the start. If a dev gets a package from a proxy-maintainer
30 and they disappear then they can nurse it along or remove it as makes
31 sense - we should be nice to these devs but we shouldn't just cut the
32 packages loose.
33
34 Packages that are maintainer-needed stay around as long as they're not
35 making trouble. If they get lots of complaints they get announced on
36 -dev, and after two weeks they get masked if not picked up. If they
37 end up blocking something then likewise they get announced and then
38 masked. That basically is the current practice anyway.
39
40 I don't see a need to remove m-n packages wholesale just to say that
41 we did it, or to punish users for not becoming devs or whatever.
42
43 And of course, the usual long-term solutions like making
44 proxy-maintaining easier should be pursued.
45
46 Rich

Replies