| 1 |
On Fri, Jul 8, 2016 at 12:51 PM, Michał Górny <mgorny@g.o> wrote: |
| 2 |
> |
| 3 |
> Now, there's a significant difference between lastriting unmaintained |
| 4 |
> packages at treecleaner's leisure and having a clean tree to work on, |
| 5 |
> and having to figure out how many of the packages blocking some global |
| 6 |
> change are unmaintained and if they can be cleaned, and cleaning them |
| 7 |
> while doing something completely different, then checking again, |
| 8 |
> then... |
| 9 |
|
| 10 |
Packages that are unmaintained are tagged as such. Perhaps we need |
| 11 |
better reporting tools to make it easier to identify blockers |
| 12 |
associated with these? |
| 13 |
|
| 14 |
Perhaps some kind of QA tool that lists all unmaintained packages that |
| 15 |
are a blocker for anything and auto-treecleans them? |
| 16 |
|
| 17 |
> |
| 18 |
> You say that there are no bugs in those packages. How do you know? You |
| 19 |
> don't know unless you test it, and no maintainer means nobody is known |
| 20 |
> to test it regularly. The package can be pretty much completely broken |
| 21 |
> and we'll not know unless someone tests it. |
| 22 |
> |
| 23 |
|
| 24 |
This sounds like a tree falling in the forest with nobody around... |
| 25 |
|
| 26 |
If a package is in the tree, and it has no known bugs, and no users, |
| 27 |
who cares? |
| 28 |
|
| 29 |
If somebody tries to use it, and it doesn't work, then they can file a |
| 30 |
bug, and then we can treeclean it. |
| 31 |
|
| 32 |
I tend to favor just leaving things alone in the tree unless there is |
| 33 |
a serious bug, or it is something sensitive enough that it just isn't |
| 34 |
worth taking the chance. |
| 35 |
|
| 36 |
However, I think broadly speaking there are two approaches that I |
| 37 |
think make some sort of sense: |
| 38 |
1. Packages stay in tree until there is a problem (serious bug, |
| 39 |
blocker, etc), then rapid and aggressive cleanout. |
| 40 |
2. Only maintained packages in tree. Have a graveyard repo for |
| 41 |
unmaintained stuff that doesn't have serious bugs (including not |
| 42 |
working due to some change introduced in the main tree), and |
| 43 |
aggressive cleanout if these criteria fail. |
| 44 |
|
| 45 |
I don't think that keeping stuff in the tree until it is broken and |
| 46 |
then moving them to a graveyard makes sense, at least not if they're |
| 47 |
seriously broken. The only use case I really see for this is people |
| 48 |
who don't know how to work git. I think a better solution for that |
| 49 |
use case is for somebody to just make a repo that contains the latest |
| 50 |
version of every file that has ever been in the gentoo repo (so, |
| 51 |
basically a replay of the scm history minus delete operations, except |
| 52 |
maybe for moves). That really should just be used as a convenience |
| 53 |
and not as an actual overlay. |
| 54 |
|
| 55 |
Having a graveyard that ONLY contains broken stuff as an overlay just |
| 56 |
doesn't make sense to me. Why would you install packages directly |
| 57 |
from it without fixing them first? Certainly for build failures you'd |
| 58 |
be forced to do this. I guess for security issues you could decide |
| 59 |
that you don't care, or that your host is in a locked room with no |
| 60 |
network access or something. However, these seem like such minor use |
| 61 |
cases that somebody could just stick the ebuilds in their own overlay |
| 62 |
if they needed them. |
| 63 |
|
| 64 |
-- |
| 65 |
Rich |
Archives