| 1 |
On Sun, Mar 24, 2013 at 3:24 PM, Ian Stakenvicius <axs@g.o> wrote: |
| 2 |
> The number of open bugs doesn't really matter, it's what those bugs |
| 3 |
> are that matters -- security bugs, sure, are of a higher priority and |
| 4 |
> can be fairly easily detected in bugzilla. |
| 5 |
|
| 6 |
Well, our current treecleaner policy seems to be that if a package |
| 7 |
isn't maintained and has any bugs open at all it is fair game. The |
| 8 |
caveat to that is that trivial bugs are grounds for fixing instead of |
| 9 |
removals (bad DEPEND atoms, simple-to-fix, etc). Google the full |
| 10 |
policy for details. |
| 11 |
|
| 12 |
I think that a better policy would be rather than having any open |
| 13 |
non-trivial bugs we list the sorts of bugs that should be grounds for |
| 14 |
removal, such as: |
| 15 |
|
| 16 |
1. Package does not build in the majority of cases on all archs. |
| 17 |
(Unkeywording is the solution for individual archs that are broken, if |
| 18 |
not easily fixable. Not building some of the time isn't grounds for |
| 19 |
removal.) |
| 20 |
|
| 21 |
2. Package has an open security bug. (Cuneiform is a borderline case |
| 22 |
of this - no exploit/CVE but I wouldn't use it on a server being fed |
| 23 |
images submitted by strangers.) |
| 24 |
|
| 25 |
3. Package is blocking another package. Maintained packages always |
| 26 |
take priority over unmaintained ones. |
| 27 |
|
| 28 |
Perhaps there are other cases which should be included, but I think |
| 29 |
this covers most of them. If a package isn't blocking anything else, |
| 30 |
doesn't have security problems, and works most of the time, then I |
| 31 |
think it should generally be kept. |
| 32 |
|
| 33 |
Rich |
Archives