On Sun, 16 Feb 2014 09:38:20 -0500
Rich Freeman <ri...@gentoo.org> wrote:

> Basically that one version of the package is now maintained by the
> arch team.  Yes, I know they won't maintain it.  The only people that
> impacts are those who use the arch, who are free to join the arch
> team and help out.  My sense is that they'd prefer having it around
> to having it deleted.

That's a bit simplistic. What if said package or its newer version is
required for dozens of other packages, or if the old ebuild needs an
outdated eclass, or if the old version has a security issue? You can't
just "assign" all of the old KDE ebuilds to an arch team, for instance,
or keep texlive 2010 in place because you have "delegated"
responsibility for it.

Also, every time *I* look at eshowkw's output for a package I maintain
(which I assume every ebuild developer does or they should hand in
their badge) and see a lingering old version, it really itches. The
mere knowledge that I have "delegated" its maintenance to someone else
wouldn't make me feel better at all. Amplify that with reverse
dependencies.

> The reason why this thread seems to go on forever is that it seems
> like the users of the minor archs don't like the status quo.

Examples? :)

> >> That leaves the choice with the minor arch team, with deletion
> >> being the default.
> >
> > Yes, but "understaffed" so nobody is making any choices here.
> 
> Well, if they make no choice then the maintainer deletes the package.
> That's what you want, right?  The package would only stay around if
> the minor arch asked them to.  If they don't do that, then nobody can
> complain.
> 
> However, I don't think it makes sense to enact changes like these
> unless the minor arch teams actually speak up about wanting the
> changes.  If they don't I'd be inclined to just clarify that
> maintainers are welcome to trim old stable versions on minor archs if
> the bugs are older than n days.

That still leaves maintenance problems on dependent packages and
eclasses and security issues and what not.

Reply via email to