1 |
On 01/11/2010 10:43 PM, Jeremy Olexa wrote: |
2 |
> (A general reply, not targeted towards you, Rich) |
3 |
|
4 |
No prob - my post wasn't really directed personally at anybody. |
5 |
|
6 |
> |
7 |
> Speaking on behalf of the treecleaners: |
8 |
> The fact is, some of us have never heard of "inn" and until Gentoo has |
9 |
> some sort of "popularity tracking" software/tool, the treecleaners will |
10 |
> continue to mask unmaintained software. |
11 |
|
12 |
Yikes - just goes to show how NNTP is starting to fade into the past. :) |
13 |
|
14 |
I'm not sure if it would cause undue overhead, but perhaps a solution |
15 |
would be to: |
16 |
|
17 |
1. Open a bug stating that the package will be discarded - assign to |
18 |
the maintainer. This gives the maintainer a chance to wake up. You can |
19 |
even do this without having to try to contact them first which might |
20 |
save you a step if you're doing that now. |
21 |
|
22 |
2. Periodically post a list of packages that have said bugs logged for |
23 |
more than two weeks on -dev-announce - reference the bug number. That |
24 |
gives the community at large a chance to pick up the package. |
25 |
|
26 |
3. In another two weeks, if some dev hasn't stepped in to maintain, |
27 |
then mask as usual. Don't announce this since anybody who cares should |
28 |
have CC'ed themselves on the bug. |
29 |
|
30 |
4. Of course, security issues / etc take priority and appropriate |
31 |
action is taken quickly (try to find a maintainer, but mask otherwise). |
32 |
|
33 |
I'd think that if you tagged bugs appropriately you could largely |
34 |
automate #2 and #3 - just query for bugs over a certain age with a given |
35 |
keyword or whatever. |
36 |
|
37 |
This would probably lengthen the time needed to get rid of a package, |
38 |
but it wouldn't really increase the work needed by too much. You |
39 |
already announce on the list that you're masking packages - now you'd |
40 |
announce two weeks earlier and skip the announcement when the mask is made. |
41 |
|
42 |
This is just a suggestion, but it does eliminate the need to try to make |
43 |
judgment calls about whether a given package is or isn't "important." |
44 |
|
45 |
Rich |