Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)

[Michael Mol]

On Tuesday, January 3, 2017 9:24:19 AM EST Damien LEVAC wrote:
> On 01/03/2017 09:14 AM, Michael Mol wrote:
> > On Tuesday, January 3, 2017 12:05:10 PM EST Michał Górny wrote:
> >> On Tue, 3 Jan 2017 16:00:52 +0700 (+07)
> >>
> >> grozin@g.o wrote:
> >>> On Mon, 2 Jan 2017, Brian Evans wrote:
> >>>> IMO, this one should be given last-rites as upstream is dead and it
> >>>> heavily depends on wireless-tools and WEXT.
> >>>
> >>> I use it on 2 notebooks. It works fine, and is (from my point of view)
> >>> the
> >>> most convenient tool to control ethernet and wifi connections on a
> >>> notebook. Why lastrite it when it works?
> >>
> >> This is the Gentoo Way™. Having a working software is not a goal.
> >> Gentoo focuses on the best bleeding edge experience and therefore
> >> highly relies on software packages that are under active development
> >> and require active maintenance. The packages in early stages of
> >> development are especially interesting since they can supply users
> >> and developers with variety of interesting bugs and unpredictable
> >> issues.
> >
> > Do we have detailed treatise documenting the points and counterpoints to
> > "Why lastrite it when it works?" It's a question that comes up every
> > month or two, and the reasons, for and against, are probably mature
> > enough to get numbers, now.
> >
> > Reason #3 in favor: "It works for me" may only be valid from a particular
> > perspective. Without active maintenance, there may be subtle bugs that
> > aren't immediately obvious. Bugs that aren't immediately obvious aren't
> > always innocuous; sometimes they're insidious background data loss. Other
> > times, they might be security vulnerabilities no good guy has yet
> > noticed.
>
> ...and sometimes a package just stop being "actively" maintained because
> it is feature-complete (as far as the goals of the project were
> concerned) and just works.
>
> The minimum conditions to lastrite something should be not actively
> maintained _and_ with open bugs

What happens when the bugs exist, but nobody knows they're there? Let's say 
someone got a copy of Coverity and ran it on long-stable, ridiculously mature 
packages. They get a bunch of hits, but they keep it to themselves and instead 
develop exploits for the bugs they found.

For security's sake, even mature software needs, at minimum, routine auditing. 
Unless someone's doing that work, the package should be considered for 
removal. (Call that reason #	π, in honor of TeX.)

(I'm really not trying to start yet another massive thread on the subject, 
hence my original question: Do we have a documented treatise on the question? 
Not "Gentoo's Official Policy", but rather the rationales and counterpoints?)