On Mon, Jul 4, 2016 at 4:40 PM, Andrew Savchenko <birc...@gentoo.org> wrote:
>
> The same applies for the tree-cleaners team. While their job is
> very important, sometimes they are too hasty, like in commit
> 34181a1045d13142d959b9c894a46ddcebf3c512. If package builds and
> works fine, have no critical bugs opened, the sheer fact that
> upstream as inactive and package has no maintainer is no valid to
> remove package. The reason "are still sitting in ~arch" is even
> less valid, since it is absolutely fine that package never mades it
> into stable (some people do not use stable at all).
>

++

To treeclean a package it should be both unmaintained and have a
significant QA issue of some kind.  Simply having open bugs shouldn't
be sufficient, and of course if it works fine there is no reason to
boot it.  Now, if the package is a blocker on some EAPI retirement or
other tree-wide operation, that would be a great reason to treeclean
it if it is unmaintained.

Security issues should warrant masking fairly easily, but only if the
maintainer is unresponsive or the package is unmaintained (or we're
talking an end-of-the-world security issue).  If the maintainer is
about to commit a fix or disputes that the issue applies in the
package, it is best to just work with them.  Otherwise users will just
end up putting entries in package.unmask that could cause them issues
later.

-- 
Rich

Reply via email to