Re: [gentoo-dev] Last rites: app-text/cuneiform

[Alec Warner]

On Sun, Mar 24, 2013 at 4:40 PM, Rich Freeman <rich0@g.o> wrote:
> On Sun, Mar 24, 2013 at 3:24 PM, Ian Stakenvicius <axs@g.o> wrote:
>> The number of open bugs doesn't really matter, it's what those bugs
>> are that matters -- security bugs, sure, are of a higher priority and
>> can be fairly easily detected in bugzilla.
>
> Well, our current treecleaner policy seems to be that if a package
> isn't maintained and has any bugs open at all it is fair game.  The
> caveat to that is that trivial bugs are grounds for fixing instead of
> removals (bad DEPEND atoms, simple-to-fix, etc).  Google the full
> policy for details.

So Treecleaners exists to do two jobs.

1) Keep the number of packages in the tree from growing out of
control. It is easier to add software to the tree than to remove it.
There is no policy for adding software to the tree (in terms of
minimum # of users, etc.) There is a policy for removal. Prior to the
policy being adopted, I would remove packages without notice (or
often, without masking.) This angered people, which is why the policy
was adopted; to inform users why a package was being removed, and what
they could do about it. This is why the masks exist at all.

2) Remove dead packages. This is perhaps the more hotly debated
section. My intention was not to remove packages that compiled and
worked, but had bugs. I think your statement about buggy packages is
apt. In many cases the target of TreeCleaners was portions of the tree
that were basically under-maintained and dead. This consisted of
software that did not build, or built, but did not run. Generally
security bugs were already taken by security@ (in 2007 anyway.)

Sometimes users are using dead packages. One of the reasons why
proxy-maint was established was to get interested users to step up and
maintain the packages they wanted; in the beginning I wanted
TreeCleaners to be 'maintainer-needed' and fix up all the broken
packages. Sadly though, there are too many broken packages for such a
small team.

-A

>
> I think that a better policy would be rather than having any open
> non-trivial bugs we list the sorts of bugs that should be grounds for
> removal, such as:
>
> 1.  Package does not build in the majority of cases on all archs.
> (Unkeywording is the solution for individual archs that are broken, if
> not easily fixable.  Not building some of the time isn't grounds for
> removal.)
>
> 2.  Package has an open security bug.  (Cuneiform is a borderline case
> of this - no exploit/CVE but I wouldn't use it on a server being fed
> images submitted by strangers.)
>
> 3.  Package is blocking another package.  Maintained packages always
> take priority over unmaintained ones.
>
> Perhaps there are other cases which should be included, but I think
> this covers most of them.  If a package isn't blocking anything else,
> doesn't have security problems, and works most of the time, then I
> think it should generally be kept.
>
> Rich
>