| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
Dne 27.3.2011 15:44, Rich Freeman napsal(a): |
| 5 |
> On Sun, Mar 27, 2011 at 9:30 AM, Jeremy Olexa <darkside@g.o> wrote: |
| 6 |
>> On 03/27/2011 02:47 AM, Nirbheek Chauhan wrote: |
| 7 |
>>>> On 03/26/2011 12:52 AM, Mike Frysinger (vapier) wrote: |
| 8 |
>>> I propose that we should be more aggressive about package.masking (for |
| 9 |
>>> removal) all maintainer-needed packages from the tree by doing that |
| 10 |
>>> one month after they become maintainer-needed. If someone doesn't |
| 11 |
>>> volunteer to take care of it, it probably wasn't important anyway. |
| 12 |
>>> |
| 13 |
>> |
| 14 |
>> That is abit extreme for me (read: I don't have motivation to fight the |
| 15 |
>> flames), but I wouldn't complain if someone else did it to be honest. |
| 16 |
>> |
| 17 |
> |
| 18 |
> So, I'd like to propose that somewhere between adding stuff to the |
| 19 |
> tree that nobody has any intent to look after, and removing stuff that |
| 20 |
> has been around a long time with no clear problems, there is a happy |
| 21 |
> medium. |
| 22 |
> |
| 23 |
> How about this - if you add a package to the tree, you are responsible |
| 24 |
> for it for at least a year. If you can get somebody else to take it |
| 25 |
> then that is fine. If it has problems QA can flame you (privately at |
| 26 |
> first) for it, and you should feel appropriately embarrassed and fix |
| 27 |
> it, or remove it. |
| 28 |
> |
| 29 |
> After a year, it can go maintainer-needed. Before a year, it cannot, |
| 30 |
> and you either need to actually maintain it, or remove it. Developers |
| 31 |
> should not be adding packages they have no interest in whatsoever, or |
| 32 |
> that have so many QA issues initially that they're high-maintenance |
| 33 |
> right from the start. If a dev gets a package from a proxy-maintainer |
| 34 |
> and they disappear then they can nurse it along or remove it as makes |
| 35 |
> sense - we should be nice to these devs but we shouldn't just cut the |
| 36 |
> packages loose. |
| 37 |
> |
| 38 |
> Packages that are maintainer-needed stay around as long as they're not |
| 39 |
> making trouble. If they get lots of complaints they get announced on |
| 40 |
> -dev, and after two weeks they get masked if not picked up. If they |
| 41 |
> end up blocking something then likewise they get announced and then |
| 42 |
> masked. That basically is the current practice anyway. |
| 43 |
> |
| 44 |
> I don't see a need to remove m-n packages wholesale just to say that |
| 45 |
> we did it, or to punish users for not becoming devs or whatever. |
| 46 |
> |
| 47 |
> And of course, the usual long-term solutions like making |
| 48 |
> proxy-maintaining easier should be pursued. |
| 49 |
> |
| 50 |
> Rich |
| 51 |
> |
| 52 |
And how exactly you want to track the level of failure for the package? |
| 53 |
Since nobody is watching them already we usually don't know how much |
| 54 |
they fail until somebody tries to emerge them from dev team or notify QA |
| 55 |
by adding as CC to bug... |
| 56 |
-----BEGIN PGP SIGNATURE----- |
| 57 |
Version: GnuPG v2.0.17 (GNU/Linux) |
| 58 |
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ |
| 59 |
|
| 60 |
iEYEARECAAYFAk2PT5MACgkQHB6c3gNBRYdepgCfYUo00PKNQFoa+ZaqGoPTHOuv |
| 61 |
Dd8Ani+d1sa/jIHvrWyZrwOF3UUkESl8 |
| 62 |
=k1EI |
| 63 |
-----END PGP SIGNATURE----- |
Archives