| 1 |
On Mon, Jul 4, 2016 at 4:40 PM, Andrew Savchenko <bircoph@g.o> wrote: |
| 2 |
> |
| 3 |
> The same applies for the tree-cleaners team. While their job is |
| 4 |
> very important, sometimes they are too hasty, like in commit |
| 5 |
> 34181a1045d13142d959b9c894a46ddcebf3c512. If package builds and |
| 6 |
> works fine, have no critical bugs opened, the sheer fact that |
| 7 |
> upstream as inactive and package has no maintainer is no valid to |
| 8 |
> remove package. The reason "are still sitting in ~arch" is even |
| 9 |
> less valid, since it is absolutely fine that package never mades it |
| 10 |
> into stable (some people do not use stable at all). |
| 11 |
> |
| 12 |
|
| 13 |
++ |
| 14 |
|
| 15 |
To treeclean a package it should be both unmaintained and have a |
| 16 |
significant QA issue of some kind. Simply having open bugs shouldn't |
| 17 |
be sufficient, and of course if it works fine there is no reason to |
| 18 |
boot it. Now, if the package is a blocker on some EAPI retirement or |
| 19 |
other tree-wide operation, that would be a great reason to treeclean |
| 20 |
it if it is unmaintained. |
| 21 |
|
| 22 |
Security issues should warrant masking fairly easily, but only if the |
| 23 |
maintainer is unresponsive or the package is unmaintained (or we're |
| 24 |
talking an end-of-the-world security issue). If the maintainer is |
| 25 |
about to commit a fix or disputes that the issue applies in the |
| 26 |
package, it is best to just work with them. Otherwise users will just |
| 27 |
end up putting entries in package.unmask that could cause them issues |
| 28 |
later. |
| 29 |
|
| 30 |
-- |
| 31 |
Rich |
Archives