On 01/03/2017 09:57 AM, Michael Mol wrote:
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)
gro...@gentoo.org 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?)
But routine auditing, while being wishful thinking in the open-source
world (even when the projects are alive), are not meant to find those
kind of bugs anyway (and wouldn't be effective at doing so either).
I would argue that those concerns apply to every packages to different
degree and you might not be safer (on the contrary) with a maintained
but more experimental package...
Even if just for the sake of stability, shouldn't there be a policy of
inertia? I.e. if it is not broken it does not need fixing, or something
like that? Like you said, this topic comes every once in a while and
every time it is a waste of time. Unless there is an unknown maintaining
cost in having it in the tree unmaintained?
