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