On 07/08/2016 10:33 AM, Andrew Savchenko wrote:
On Fri, 8 Jul 2016 10:11:45 -0500 William Hubbs wrote:
I'm starting a new thread so this will be a completely separate
discussion.
On Fri, Jul 08, 2016 at 05:56:04PM +0300, Andrew Savchenko wrote:
On Fri, 8 Jul 2016 10:42:14 -0400 Rich Freeman wrote:
On Fri, Jul 8, 2016 at 10:30 AM, Anthony G. Basile <bluen...@gentoo.org> wrote:
Also there's some debate in IRC about whether or not these packages
should be lastrited or dropped to maintainer-needed. These forks are
not in good shape upstream, so I think it makes better sense to
p.mask/lastrite and then move them to the graveyard overlay when I
remove them from the tree in 30 days.
IMO the criteria should be whether they work or not. Not whether
upstream is more or less active.
If they're blockers on other work, by all means cull them. However,
if the biggest problem with them is that they're using a few inodes in
the repo, then they should probably stay.
+1
Best regards,
Andrew Savchenko
There is also an overlay for packages that are removed from the official
tree [1], and imo that is where old software should go if it doesn't
have an active maintainer.
I disagree with the criteria. Old is not necessarily sufficiently
broken. Granted every package should have a maintainer, but the lack
thereof is not sufficient for removal.
I don't know why we haven't been using this, but using it more than we
have makes a lot of sense.
NP-H. just published a basic guide on how to resurrect packages from
github. Perhaps that should be tested by both devs and users, and
modified and further documented to be compatible with 'the graveyard
overlay' and those instructions linked to the graveyard.
In the future, the graveyard will itself look like the gentoo tree,
except for the actual package contained therein, including categories
and files ? Patches? Sources ? How is the graveyard going to look and
function for retrieval a year or two from now? Bare-bones copies of
ebuilds only? Just like the attic, this 'graveyard' will be visited
often for package to be returned at least to a user's
/usr/local/portage. So why not implement the full set of tooling for
such needs
into the graveyard concept ?
When software is in the main tree, it is a subject of tree-wide
changes like GLEP 67 update, package moves and so on. In a
separated overlay it will be completely abandoned and it may create
inter-overlay dependencies issues (e.g. when A is an old
package from the tree and package B from some overlay depends on A,
so if A will move to graveyard, B will be broken).
I completely do not understand why having "old" software in tree is
a problem, if such software have no serious issues and is not
blocking major progress. If software _is_ sufficiently broken, then
indeed move it to graveyard.
As I said yesterday on IRC, one of the greatest virtues of Gentoo
is its ample spectra of packages available in the main tree. I do
not understand why it should be killed for nothing.
+1
Clearly we have significant differences in the dev and user communities
on viability and usefulness of old packages. Perhaps the solution is to
be conservative on tree removal, but aggressive on concurrent status via
labeling of packages. For example, all of these issues could be added
to a simple tool like app-portage/eix to show, for example security, age
of last update and maintainer status, and any other issues deemed
significant.
Best regards,
Andrew Savchenko
hth,
James
