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

[Sam Jorna]

On Tue, Jan 17, 2017 at 04:45:39AM -0800, Daniel Campbell wrote:
> On 01/06/2017 12:46 PM, William L. Thomson Jr. wrote:
> > On Friday, January 6, 2017 9:14:54 AM EST Alec Warner wrote:
> >>
> >> The nice thing about ::graveyard or similar is that its a clear demarcation
> >> between maintained (in tree) and unmaintained (graveyard.) It also means
> >> that people doing actual maintenance work can basically ignore the
> >> graveyard as a matter of policy. The ebuilds are archived there (for users)
> >> but since they are unmaintained they may not work correctly.
> > 
> > This is what the Java team used to do. There was a java-graveyard-overlay. 
> > I 
> > do not believe any package ever moved there came back into the tree. It did 
> > result in a pretty messed up overlay, but makes it a user problem.
> > 
> > At the same time, something could always be restored from VC. Not like 
> > removal 
> > is removing all history and traces. Thus not sure such overlay is really 
> > even 
> > beneficial. Using it could cause lots of problems if they just care about 1 
> > package or a few.
> > 
> 
> There's a nice trick around that, actually: let's assume the overlay is
> called "foo-overlay".
> 
> In package.mask:
> 
> */*::foo-overlay
> 
> will mask all packages in the overlay. You can then add packages to
> package.unmask:
> 
> pkg-cat/foobar::foo-overlay
> 
> That should alleviate most issues, though it can make dependencies a
> PITA if those deps are also in the overlay. In that case, emerge should
> yell at you and suggest adding lines to package.unmask.

Another option would be to set the priority of the overlay to -1001 (one
less than gentoo.git) and explicitly emerge the package from the
overlay:

emerge -a pkg-cat/foobar::foo-overlay

Dependencies will by default be drawn from gentoo.git (if it has equal
or better version(s)), and overlay-only dependencies won't need to be
explicitly unmasked.

You may end up with gentoo.git-provided packages coming from the overlay
if they have newer versions, though when talking about graveyard, that
shouldn't be an issue.

-- 
Sam Jorna (wraeth)
GPG ID: 0xD6180C26



signature.asc
Description: Digital signature

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

[Daniel Campbell]

On 01/06/2017 12:46 PM, William L. Thomson Jr. wrote:
> On Friday, January 6, 2017 9:14:54 AM EST Alec Warner wrote:
>>
>> The nice thing about ::graveyard or similar is that its a clear demarcation
>> between maintained (in tree) and unmaintained (graveyard.) It also means
>> that people doing actual maintenance work can basically ignore the
>> graveyard as a matter of policy. The ebuilds are archived there (for users)
>> but since they are unmaintained they may not work correctly.
> 
> This is what the Java team used to do. There was a java-graveyard-overlay. I 
> do not believe any package ever moved there came back into the tree. It did 
> result in a pretty messed up overlay, but makes it a user problem.
> 
> At the same time, something could always be restored from VC. Not like 
> removal 
> is removing all history and traces. Thus not sure such overlay is really even 
> beneficial. Using it could cause lots of problems if they just care about 1 
> package or a few.
> 

There's a nice trick around that, actually: let's assume the overlay is
called "foo-overlay".

In package.mask:

*/*::foo-overlay

will mask all packages in the overlay. You can then add packages to
package.unmask:

pkg-cat/foobar::foo-overlay

That should alleviate most issues, though it can make dependencies a
PITA if those deps are also in the overlay. In that case, emerge should
yell at you and suggest adding lines to package.unmask.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature

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

[M. J. Everitt]

On 06/01/17 17:14, Alec Warner wrote:
>
> Treecleaning to me is really two things:
>
> 1) developer maintenance time.
>  a) It costs nothing to add packages to the tree, and the tree grows
> in size every year.
>  b) Removals occur due to obsolescence (X replaces Y, etc) but these
> are strictly less than the addition rate.
>  c) Treecleaning is an attempt to aid in the reducing growth rate of
> tree size by removing packages.
>  d) The concern here is nominally overall maintenance work (not a
> technical component like computing resources.)
> 2) A clear indication that this ebuild is unmaintained and may be
> broken; even if marked stable.
>  a) Nominally we have maintainer-needed or similar tags for packages
> which indicates this.
>  b) Packages tended to be tested at stabilization time, but never
> tested again[1] ( sometimes for years.)
>  c) The packages have no maintainer, so have many open bugs, and users
> shout into the void on bugzilla. This leads to a bad user experience.
>
> The nice thing about ::graveyard or similar is that its a clear
> demarcation between maintained (in tree) and unmaintained (graveyard.)
> It also means that people doing actual maintenance work can basically
> ignore the graveyard as a matter of policy. The ebuilds are archived
> there (for users) but since they are unmaintained they may not work
> correctly.
>
> [1] Tinderboxing can help here, specifically if upstream provides a
> test suite so we know the package builds and does some correct things.
>
I think a ::graveyard policy would be much better policy, with perhaps
an 'auto-clean' strategy after, say, 5 years. That way, fast-updating
users could be caught fine by the 30 day policy, and those who perhaps
don't update for a year, could be pulled up by ::graveyard. Of course,
anyone sufficiently inclined can drag something up from the archives of
either/any tree, but this would provide a better case for handling those
users who aren't constantly updating stable or running ~arch. There are
often good reasons for not updating every week, but currently Gentoo
doesn't support these users very well [self included].


signature.asc
Description: OpenPGP digital signature

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

[M. J. Everitt]

On 06/01/17 15:01, Rich Freeman wrote:
> On Thu, Jan 5, 2017 at 11:27 PM, Kent Fredric  wrote:
>> If packages had a field called "BUGS=" it could contain an array of
>> bugs a package is known to contain, but can be conditionally avoided if
>> you're careful.
>>
>> Packages with non-empty BUGS= fields would be treated as hard-masked
>> for the purpose of repoman checks, and so packages that depend on
>> specific version ranges of packages with BUGS= fields are invalid,
>> and need their own BUGS= fields.
>>
> So, while I'm not sure if this is the best way to go about it, I think
> what it does point to is there being possible benefit in creating a
> closer link between our repository and bug trackers.
>
> We've seen this come up in managing stable requests as well (having
> users be able to vote on things, having automated testing, etc).
>
> With the recent stable changes we have bugs being tagged with "atoms."
>  With your proposal we have ebuilds being tagged with bugs.
>
> I can see benefits to having a single way to associate bugs and
> ebuilds, and making those associations available to bug trackers and
> package managers.
>
> I think the question is:
> 1.  What is the best way to go about this?
> 2.  Is anybody actually going to make use of this?
>
> The intended use cases in #2 probably will influence #1.  However, it
> doesn't make sense to have multiple ways of doing these associations,
> because bugzilla doesn't know anything about the repo, and portage
> doesn't know anything about bugzilla.  Having one place to store the
> associations and tools to make that information accessible elsewhere
> makes more sense.
>
#gentoo-grumpy :) o/ leio !



signature.asc
Description: OpenPGP digital signature

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

[M. J. Everitt]

On 06/01/17 04:27, Kent Fredric wrote:
> On Tue, 3 Jan 2017 10:23:02 -0500
> Rich Freeman  wrote:
>
>> I tend to be firmly in the camp that a package shouldn't be removed
>> unless there is evidence of a serious bug (and that includes things
>> blocking other Gentoo packages).
> I would probably go further and extend that argument to older versions
> of packages, for similar reasons, at least in regards to older versions
> with specific and exclusive APIs. 
>
> Our duty as maintainers is to protect our users from the mistakes
> upstream make as much as possible, not to protect ourselves as
> maintainers from having difficult challenges.
>
> But our duty here doesn't extend to protecting users from problems the
> user knows don't affect them.
>
> If for example, a media playback suite has a memory corruption bug when
> playing media of a certain type, making it unusable when playing that
> media, it does seem reasonable for us at first to kill that suite.
>
> However, if the user in question knows they're never going to play
> that certain type of media, and only uses that media suite for a narrow
> and specific kind of problem, then we're not serving them much utility,
> or much freedom of choice by ripping this tool out of their hands for a
> problem they'll never have.
>
> Maybe we need an intermediate option, where the sensible default when
> we discover this kind of error is to remove it, but provide a way to
> easily restore that package if the users are ok with it.
>
> Like, this is not my proposal, just an idea so you can see where I'm
> headed with thoughts:
>
> If packages had a field called "BUGS=" it could contain an array of
> bugs a package is known to contain, but can be conditionally avoided if
> you're careful.
>
> Packages with non-empty BUGS= fields would be treated as hard-masked
> for the purpose of repoman checks, and so packages that depend on
> specific version ranges of packages with BUGS= fields are invalid,
> and need their own BUGS= fields.
>
> Users get portage by default telling them "X package has to go away,
> because it has bug #145 , #1286234, and #123756"
>
> And if this is not satisfactory, they can override portage with 
>
> ACCEPT_BUGS="145 1286234 123756"
>
> You could even have
>
> BUGS=" x86? ( 112345 )" 
>
> This to me sounds like a more user-empowering approach.
>
> The only questions to me are:
>
> - Do we have the resources to support this kind of strategy?
> - How much additional complexity and confusion will this introduce for
>   users?
> - Is that additional complexity and confusion something users want to
>   indulge, or is our current feature set already too complex.
>
> That last one is pretty much the one that weighs most on my mind
> lately, with users frequently stumped by handling subslot upgrades
> and required-use conflicts.
>
> Granted, this is just yet-another alternative flavour of hard-masking
> things, so I'd rather we stick with careful use of hardmasks to inform
> users of problems they might face, allowing them to contravene the hard
> masks if they're feeling like they want to be adults.
>
>
>
+1 I like this proposal .. we are supposedly a distribution of Choice
and Flexibility .. part of that is being an adult about making that
choice available, and the consequences of it ..

Just my 2c50 as usual ;)



signature.asc
Description: OpenPGP digital signature

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

[William L. Thomson Jr.]

On Friday, January 6, 2017 9:13:20 AM EST Michael Mol wrote:
>
> The bigger resource drain, I suspect, will come from maintaining new ebuilds
> of old packages; as eclass development and maintenance seeks to eliminate
> old and buggy code, old ebuilds will need to be dragged along for the ride.

This is already taking place, and has since the first EAPI. I am not opposed to 
such things, EAPI. But EAPI does lead to what I call "ebuild wheel spinning". 
Constantly revising an ebuilds internals that may or may not produce much. May 
not close any bugs, may not change installed files, may prevent future bugs. 
But does create more work, and why some stuff remains behind all the way back 
to EAPI=0.

It blows me away how some old ebuilds that should be removed, get touched and 
improved per eclass and other changes. Or things get updated, but not the 
package itself. Lots of work that produces very little end benefit.

Like revising patches for -p1, when they patch may apply fine now with epatch. 
Modifying -pN of a patch is minor, but still consumes time for very little if 
any benefit. Patch applied before, patch applies when changed to -p1. What was 
the benefit for that time spent?

-- 
William L. Thomson Jr.


signature.asc
Description: This is a digitally signed message part.

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

[William L. Thomson Jr.]

On Friday, January 6, 2017 9:14:54 AM EST Alec Warner wrote:
>
> The nice thing about ::graveyard or similar is that its a clear demarcation
> between maintained (in tree) and unmaintained (graveyard.) It also means
> that people doing actual maintenance work can basically ignore the
> graveyard as a matter of policy. The ebuilds are archived there (for users)
> but since they are unmaintained they may not work correctly.

This is what the Java team used to do. There was a java-graveyard-overlay. I 
do not believe any package ever moved there came back into the tree. It did 
result in a pretty messed up overlay, but makes it a user problem.

At the same time, something could always be restored from VC. Not like removal 
is removing all history and traces. Thus not sure such overlay is really even 
beneficial. Using it could cause lots of problems if they just care about 1 
package or a few.

-- 
William L. Thomson Jr.


signature.asc
Description: This is a digitally signed message part.

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

[Rich Freeman]

On Fri, Jan 6, 2017 at 12:14 PM, Alec Warner  wrote:
>
> So my understanding of the status quo is that maintainers get to make the
> call with regard to what is reasonable to keep or drop. I'm loathe to add
> additional policy here; mostly because the expectation is that the
> maintainer has the most state here. That doesn't mean you can't:
>

I think the main concern is with unmaintained packages.


-- 
Rich

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

[Alec Warner]

On Thu, Jan 5, 2017 at 8:27 PM, Kent Fredric  wrote:

> On Tue, 3 Jan 2017 10:23:02 -0500
> Rich Freeman  wrote:
>
> > I tend to be firmly in the camp that a package shouldn't be removed
> > unless there is evidence of a serious bug (and that includes things
> > blocking other Gentoo packages).
>
> I would probably go further and extend that argument to older versions
> of packages, for similar reasons, at least in regards to older versions
> with specific and exclusive APIs.
>
>
So my understanding of the status quo is that maintainers get to make the
call with regard to what is reasonable to keep or drop. I'm loathe to add
additional policy here; mostly because the expectation is that the
maintainer has the most state here. That doesn't mean you can't:

1) Try to convince the maintainer that older versions are needed to support
some important use case.
2) Volunteer to help in maintenance of older versions to support your
important use case.

I'm unclear on how having a more explicit policy is advantageous.


> Our duty as maintainers is to protect our users from the mistakes
> upstream make as much as possible, not to protect ourselves as
> maintainers from having difficult challenges.
>
But our duty here doesn't extend to protecting users from problems the
> user knows don't affect them.
>
> If for example, a media playback suite has a memory corruption bug when
> playing media of a certain type, making it unusable when playing that
> media, it does seem reasonable for us at first to kill that suite.
>
> However, if the user in question knows they're never going to play
> that certain type of media, and only uses that media suite for a narrow
> and specific kind of problem, then we're not serving them much utility,
> or much freedom of choice by ripping this tool out of their hands for a
> problem they'll never have.
>
> Maybe we need an intermediate option, where the sensible default when
> we discover this kind of error is to remove it, but provide a way to
> easily restore that package if the users are ok with it.
>
> Like, this is not my proposal, just an idea so you can see where I'm
> headed with thoughts:
>
> If packages had a field called "BUGS=" it could contain an array of
> bugs a package is known to contain, but can be conditionally avoided if
> you're careful.
>
> Packages with non-empty BUGS= fields would be treated as hard-masked
> for the purpose of repoman checks, and so packages that depend on
> specific version ranges of packages with BUGS= fields are invalid,
> and need their own BUGS= fields.
>
> Users get portage by default telling them "X package has to go away,
> because it has bug #145 , #1286234, and #123756"
>
> And if this is not satisfactory, they can override portage with
>
> ACCEPT_BUGS="145 1286234 123756"
>
> You could even have
>
> BUGS=" x86? ( 112345 )"
>
> This to me sounds like a more user-empowering approach.
>

Treecleaning to me is really two things:

1) developer maintenance time.
 a) It costs nothing to add packages to the tree, and the tree grows in
size every year.
 b) Removals occur due to obsolescence (X replaces Y, etc) but these are
strictly less than the addition rate.
 c) Treecleaning is an attempt to aid in the reducing growth rate of tree
size by removing packages.
 d) The concern here is nominally overall maintenance work (not a technical
component like computing resources.)
2) A clear indication that this ebuild is unmaintained and may be broken;
even if marked stable.
 a) Nominally we have maintainer-needed or similar tags for packages which
indicates this.
 b) Packages tended to be tested at stabilization time, but never tested
again[1] ( sometimes for years.)
 c) The packages have no maintainer, so have many open bugs, and users
shout into the void on bugzilla. This leads to a bad user experience.

The nice thing about ::graveyard or similar is that its a clear demarcation
between maintained (in tree) and unmaintained (graveyard.) It also means
that people doing actual maintenance work can basically ignore the
graveyard as a matter of policy. The ebuilds are archived there (for users)
but since they are unmaintained they may not work correctly.

[1] Tinderboxing can help here, specifically if upstream provides a test
suite so we know the package builds and does some correct things.


The only questions to me are:
>
> - Do we have the resources to support this kind of strategy?
> - How much additional complexity and confusion will this introduce for
>   users?
> - Is that additional complexity and confusion something users want to
>   indulge, or is our current feature set already too complex.
>

> That last one is pretty much the one that weighs most on my mind
> lately, with users frequently stumped by handling subslot upgrades
> and required-use conflicts.
>
> Granted, this is just yet-another alternative flavour of hard-masking
> things, so I'd rather we stick with careful use of hardmasks to inform
> 

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

[Rich Freeman]

On Thu, Jan 5, 2017 at 11:27 PM, Kent Fredric  wrote:
>
> If packages had a field called "BUGS=" it could contain an array of
> bugs a package is known to contain, but can be conditionally avoided if
> you're careful.
>
> Packages with non-empty BUGS= fields would be treated as hard-masked
> for the purpose of repoman checks, and so packages that depend on
> specific version ranges of packages with BUGS= fields are invalid,
> and need their own BUGS= fields.
>

So, while I'm not sure if this is the best way to go about it, I think
what it does point to is there being possible benefit in creating a
closer link between our repository and bug trackers.

We've seen this come up in managing stable requests as well (having
users be able to vote on things, having automated testing, etc).

With the recent stable changes we have bugs being tagged with "atoms."
 With your proposal we have ebuilds being tagged with bugs.

I can see benefits to having a single way to associate bugs and
ebuilds, and making those associations available to bug trackers and
package managers.

I think the question is:
1.  What is the best way to go about this?
2.  Is anybody actually going to make use of this?

The intended use cases in #2 probably will influence #1.  However, it
doesn't make sense to have multiple ways of doing these associations,
because bugzilla doesn't know anything about the repo, and portage
doesn't know anything about bugzilla.  Having one place to store the
associations and tools to make that information accessible elsewhere
makes more sense.

-- 
Rich

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

[Michael Mol]

On Friday, January 6, 2017 5:27:24 PM EST Kent Fredric wrote:
> On Tue, 3 Jan 2017 10:23:02 -0500
> 
> Rich Freeman  wrote:
> > I tend to be firmly in the camp that a package shouldn't be removed
> > unless there is evidence of a serious bug (and that includes things
> > blocking other Gentoo packages).
> 
> I would probably go further and extend that argument to older versions
> of packages, for similar reasons, at least in regards to older versions
> with specific and exclusive APIs.
> 
> Our duty as maintainers is to protect our users from the mistakes
> upstream make as much as possible, not to protect ourselves as
> maintainers from having difficult challenges.
> 
> But our duty here doesn't extend to protecting users from problems the
> user knows don't affect them.
> 
> If for example, a media playback suite has a memory corruption bug when
> playing media of a certain type, making it unusable when playing that
> media, it does seem reasonable for us at first to kill that suite.
> 
> However, if the user in question knows they're never going to play
> that certain type of media, and only uses that media suite for a narrow
> and specific kind of problem, then we're not serving them much utility,
> or much freedom of choice by ripping this tool out of their hands for a
> problem they'll never have.
> 
> Maybe we need an intermediate option, where the sensible default when
> we discover this kind of error is to remove it, but provide a way to
> easily restore that package if the users are ok with it.
> 
> Like, this is not my proposal, just an idea so you can see where I'm
> headed with thoughts:
> 
> If packages had a field called "BUGS=" it could contain an array of
> bugs a package is known to contain, but can be conditionally avoided if
> you're careful.
> 
> Packages with non-empty BUGS= fields would be treated as hard-masked
> for the purpose of repoman checks, and so packages that depend on
> specific version ranges of packages with BUGS= fields are invalid,
> and need their own BUGS= fields.
> 
> Users get portage by default telling them "X package has to go away,
> because it has bug #145 , #1286234, and #123756"
> 
> And if this is not satisfactory, they can override portage with
> 
> ACCEPT_BUGS="145 1286234 123756"
> 
> You could even have
> 
> BUGS=" x86? ( 112345 )"
> 
> This to me sounds like a more user-empowering approach.

I really like where this is going.

> 
> The only questions to me are:
> 
> - Do we have the resources to support this kind of strategy?

How much of the work can be automated? I.e. can bugs on bgo be tagged such 
that a maintainer's script can scoop up the bugs and apply them, at least 
naively? Being able to express something like "x86? (!mmx)" clearly in a bgo 
ticket's metadata could well be useful, and would lend itself to something 
like this.

The bigger resource drain, I suspect, will come from maintaining new ebuilds 
of old packages; as eclass development and maintenance seeks to eliminate old 
and buggy code, old ebuilds will need to be dragged along for the ride.

> - How much additional complexity and confusion will this introduce for
>   users?

I think you'd want autounmask to not support applying changes for 
automatically unmasking bugs. Apart from that, it shouldn't result in any 
additional complexity or confusion for users who aren't deliberately holding 
on to package versions that have known bugs. Most of the users I've seen who 
would be faced with this functionality are the users who will run a gymnastics 
course just to use a browser version that has an old, familiar interface.

> - Is that additional complexity and confusion something users want to
>   indulge, or is our current feature set already too complex.

So long as it stays out of a user's way until the user needs it, I wouldn't 
say it adds needless complexity from a user's perspective.

> 
> That last one is pretty much the one that weighs most on my mind
> lately, with users frequently stumped by handling subslot upgrades
> and required-use conflicts.

Choosing to engage with this functionality sounds like very much an opt-in 
experience for the user; the path of least resistance is to go ahead and 
update (and that will generally provide the best-tested global configuration), 
but if they wish to hold on to difficult configurations, they can at least do 
that.

There is one other advantage to a system like this; it permits for a larger, 
deeper tree, with old versions more frequently available. That'll significantly 
assist the upgrade efforts of people who go ridiculous amounts of time between 
@world updates, people who are dusting off stowed systems, etc.

> 
> Granted, this is just yet-another alternative flavour of hard-masking
> things, so I'd rather we stick with careful use of hardmasks to inform
> users of problems they might face, allowing them to contravene the hard
> masks if they're feeling like they want to be adults.



signature.asc

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

[Kent Fredric]

On Tue, 3 Jan 2017 10:23:02 -0500
Rich Freeman  wrote:

> I tend to be firmly in the camp that a package shouldn't be removed
> unless there is evidence of a serious bug (and that includes things
> blocking other Gentoo packages).

I would probably go further and extend that argument to older versions
of packages, for similar reasons, at least in regards to older versions
with specific and exclusive APIs. 

Our duty as maintainers is to protect our users from the mistakes
upstream make as much as possible, not to protect ourselves as
maintainers from having difficult challenges.

But our duty here doesn't extend to protecting users from problems the
user knows don't affect them.

If for example, a media playback suite has a memory corruption bug when
playing media of a certain type, making it unusable when playing that
media, it does seem reasonable for us at first to kill that suite.

However, if the user in question knows they're never going to play
that certain type of media, and only uses that media suite for a narrow
and specific kind of problem, then we're not serving them much utility,
or much freedom of choice by ripping this tool out of their hands for a
problem they'll never have.

Maybe we need an intermediate option, where the sensible default when
we discover this kind of error is to remove it, but provide a way to
easily restore that package if the users are ok with it.

Like, this is not my proposal, just an idea so you can see where I'm
headed with thoughts:

If packages had a field called "BUGS=" it could contain an array of
bugs a package is known to contain, but can be conditionally avoided if
you're careful.

Packages with non-empty BUGS= fields would be treated as hard-masked
for the purpose of repoman checks, and so packages that depend on
specific version ranges of packages with BUGS= fields are invalid,
and need their own BUGS= fields.

Users get portage by default telling them "X package has to go away,
because it has bug #145 , #1286234, and #123756"

And if this is not satisfactory, they can override portage with 

ACCEPT_BUGS="145 1286234 123756"

You could even have

BUGS=" x86? ( 112345 )" 

This to me sounds like a more user-empowering approach.

The only questions to me are:

- Do we have the resources to support this kind of strategy?
- How much additional complexity and confusion will this introduce for
  users?
- Is that additional complexity and confusion something users want to
  indulge, or is our current feature set already too complex.

That last one is pretty much the one that weighs most on my mind
lately, with users frequently stumped by handling subslot upgrades
and required-use conflicts.

Granted, this is just yet-another alternative flavour of hard-masking
things, so I'd rather we stick with careful use of hardmasks to inform
users of problems they might face, allowing them to contravene the hard
masks if they're feeling like they want to be adults.





pgpysN544Xf3x.pgp
Description: OpenPGP digital signature

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

[Thomas Kahle]

On 03/01/2017 15:24, 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.

Certainly not the case here.  wicd generates lots of complaints from
users and upstream does not exist.  Sometimes distro maintainers float a
patch, but it is definitely in a problematic situation.


> The minimum conditions to lastrite something should be not actively
> maintained _and_ with open bugs that either compromise security or
> affect normal usage subject to the condition that it is not still used
> by users. I do not think at this point in time Gentoo devs have any mean
> to know the popularity of different packages, but that would be a must
> to take proper decision as far as retiring packages goes.
> 
> -- Just a random Gentoo user.
> 

-- 
Thomas Kahle
http://dev.gentoo.org/~tomka/



signature.asc
Description: OpenPGP digital signature

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

[Matthew Thode]

On 01/03/2017 09:10 AM, Kristian Fiskerstrand wrote:
> On 01/03/2017 03:57 PM, Michael Mol wrote:
>> 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.)
> 
> A distinction here likely needs to be made between actively maintained
> upstream and actively Gentoo maintained as well. Actively maintained
> upstream might not be an issue for a feature complete package, but if it
> lacks a Gentoo-maintainer in addition it is worrying.
> 

Agreed, the main thing a package needs is a responsive packager.  If the
packager finds an issue with a package that they can't fix and upstream
is non-responsive then the packager is probably responsible for
tree-cleaning themselves.

-- 
Matthew Thode (prometheanfire)



signature.asc
Description: OpenPGP digital signature

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

[Matthew Thode]

On 01/03/2017 09:11 AM, Damien LEVAC wrote:
> 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 think it's wishful thinking in every world :P

> 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?


-- 
Matthew Thode (prometheanfire)



signature.asc
Description: OpenPGP digital signature

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

[james]

On 01/03/2017 10:41 AM, Alice Ferrazzi wrote:

On Wed, Jan 4, 2017 at 12:23 AM, Rich Freeman  wrote:

On Tue, Jan 3, 2017 at 9:57 AM, Michael Mol  wrote:


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.)



Are you suggesting that we should ban any package from the tree if we
don't have evidence of it having recently being subjected to a
security audit?  We might literally have 3 packages left in the tree
in that case, probably not including the kernel (forget the GNU/Linux
debate, we might be neither).

The fact that a project gets 47 commits and 100 list posts a week
doesn't mean that it is being security audited, or that security is
any kind of serious consideration in how their workflow operates.

I tend to be firmly in the camp that a package shouldn't be removed
unless there is evidence of a serious bug (and that includes things
blocking other Gentoo packages).  If somebody wants to come up with a
"curated" overlay or some way of tagging packages that are considered
extra-secure that would be a nice value-add, but routine auditing is
not a guarantee we provide to our users.  The lack of such an audit
should not be a reason to treeclean.


+1



Rich


Not only do I agree with those sentiments express here (Rich's 
sentiments), I have an additional prospective. I have been deeply 
following the development of clusters, particularly "in-house" clusters

run on less than a dozen systems. There are an endless number of uses
for such clusters, kinda like the modern version of when "X" servers 
were all the rage decades (and decades) ago, at the very least. In fact 
the cluster space for in-house clusters, imho, will eventually end up, 
being a collection of tarballs (stage-4s in gentoo case) that are 
customized for thousands of finely tuned, secure needs. "Unikernels" is 
the current buzzword, that docker and others have been using. [1] and 
have a tightly and minimized framework. Folks that work for "Cloud 
Vendors" should understand that if individuals and small companies are
able to build and run localize, small clusters, then is very easy and 
comfortable for them to expand into hybrid clusters and become 
comfortable with outsourcing to the cloud. Many larger companies I 
consult with or have conversations with, are still uncomfortable with
"cloud" anything. In-house clusters are the gateway to growing the 
entire cloud business, imho.



Many of those old and stable codes, that lots of folks are so keen on 
purging from the tree, are actually quite useful and easy to secure,

for such custom frameworks. Those frameworks can easily be packaged up
into a stage-4 or a forked gentoo  distro or implemented via any number 
of deployment methods, included CoreOS's fleet, recently added to 
portage. Security is the pivotal issue with clusters, whether they are 
in-house or outsourced (the cloud/Paas/Saas/etc) imho.



So keeping those old codes around makes my life easier and more 
interesting. Sure I can go to these old codes and resurrect most, as 
needed, but why be vindictive by purging things that are old? Does the 
younger and more progressive devs in gentoo really want to purge old 
C-hacks like me from the community? I do not mean to offend anyone, but 
it just seems to me to be just plain unjustified purging useful that are 
currently not popular codes, and that hurts me on a personal basis. Us 
'old farts' are the unix historians, here at gentoo; perhaps the more 
aggressive devs will consider being 'politically correct' towards old 
farts that have decades and decades of history, with these old codes?



 Newer codes are valuable too, but often they add a layer of complexity 
and many attack surfaces, that older codes do not suffer from. So, I 
would hope we err on the side of keeping ebuilds  of old codes around as 
long as possible, despite the download count. My work is liable to take 
another year or two to bear fruit, but that's not even the point. I 
would be excited if we could just move these old packages to an overlay, 
if/when they do have to be pruned from the gentoo-proper tree. Perhaps 
the new GLEP on formalizing forking gentoo, will lead to a gentoo-legacy 
fork, just for historical and nostalgic reasons?



I'm betting that these old codes are much more useful than most have 
figured, but it's going to take some time to establish this performance 
and superior security  postulate, as I use 'old-fart' methodologies.



hth,
James

[1] http://unikernel.org/blog/2015/unikernels-meet-docker

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

[Rich Freeman]

On Tue, Jan 3, 2017 at 11:09 AM, Michael Mol  wrote:
>
> Ideas like this is one reason I'm looking for a corpus of pros and cons for
> treecleaning. I don't see it as black and white. But having ideas like these
> brought up is at least useful.
>

Sure, and almost any rule has its exceptions.  My throwing out my
opinion should be viewed as intended to add to the conversation, not
halt it.  I do think we should have a policy to keep stuff unless
there is a good reason to remove it, but perhaps those reasons extend
beyond the examples I gave.

-- 
Rich

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

[Michael Mol]

On Tuesday, January 3, 2017 10:23:02 AM EST Rich Freeman wrote:
> On Tue, Jan 3, 2017 at 9:57 AM, Michael Mol  wrote:
> > 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.)
> 
> Are you suggesting that we should ban any package from the tree if we
> don't have evidence of it having recently being subjected to a
> security audit? 

Of course not. Full security audits are stupid expensive, be it in terms of 
money, time or labor. It Would Be Nice if they at least periodically got 
subjected to -Werror -Wall from time to time, or at least a linter check, or 
some tie-in to Coverity, with the results considered, but even that's going to 
be too much to ask an upstream to accept patches for.

Besides, there are going to be vulnerabilities that come from combinations of 
packages and their environments; something that's fine on x86 might have a 
critical vulnerability on arm. Something that's fine on x86_64 might have a bug 
that only presents itself in a constrained address space like x86. Something 
that's generally fine on its own might have a subtle bug that only manifests 
when a particular version of another package's headers are present at build 
time.

It's ludicrous to be absolutist about security. As I remarked to someone the 
other day, there are always more things to fix or secure than you'll have 
resources to follow though on. If someone one think a system is as secure as 
it can possibly be, then they're not as clever as they think they are.

> We might literally have 3 packages left in the tree
> in that case, probably not including the kernel (forget the GNU/Linux
> debate, we might be neither).
> 
> The fact that a project gets 47 commits and 100 list posts a week
> doesn't mean that it is being security audited, or that security is
> any kind of serious consideration in how their workflow operates.

I'm sure we all remember Heartbleed.

> 
> I tend to be firmly in the camp that a package shouldn't be removed
> unless there is evidence of a serious bug (and that includes things
> blocking other Gentoo packages).  If somebody wants to come up with a
> "curated" overlay or some way of tagging packages that are considered
> extra-secure that would be a nice value-add,

Ideas like this is one reason I'm looking for a corpus of pros and cons for 
treecleaning. I don't see it as black and white. But having ideas like these 
brought up is at least useful.

> but routine auditing is
> not a guarantee we provide to our users.  The lack of such an audit
> should not be a reason to treeclean.

I'm not trying to drive a "clean all the things" campaign. Rather, I'm 
principally interested in having a list of the standard arguments one way or 
another, for reference in the inevitable "why should this get cleaned up? It 
works." threads.

There's an old joke that goes something like this:

> Joe is going to his first comedian's convention. He's excited to see all 
> these funny people in person.

> The opening session begins with Robert, who gets up and says, "42!" Everyone 
> busts a gut laughing. Then Susan gets up and says, "73!" Again, everyone 
> laughs.

> Joe asks the guy next to him, "What's going on? I don't get it."

> "Oh, you see, everyone's heard all the same jokes over and over, so to save 
time, they reference them by number."

> "Ah! Let me give it a try."

> Joe stands up and says, "3!" Nobody laughs. Embarassed, Joe sits back down.

> "I don't understand," Joe says to the guy next to him. Why didn't anyone 
> laugh? Was 3 a poor joke?

> "Oh, no, 3 is fine, but the key is in the timing!"

Essentially, I'm looking for the joke book. Because these recurring threads 
would be a lot more interesting and less time-consuming and frictive if 
recurring material could be quickly identified and referenced. And then someone 
who still has a point to make can say, "Well, 3 is more important than 7, and 
here's why." And then have less spilling of words and boiling of blood 
irritating everyone and hardening positions before we get to consider 
something new.

signature.asc
Description: This is a digitally signed message part.

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

[Alice Ferrazzi]

On Wed, Jan 4, 2017 at 12:23 AM, Rich Freeman  wrote:
> On Tue, Jan 3, 2017 at 9:57 AM, Michael Mol  wrote:
>>
>> 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.)
>>
>
> Are you suggesting that we should ban any package from the tree if we
> don't have evidence of it having recently being subjected to a
> security audit?  We might literally have 3 packages left in the tree
> in that case, probably not including the kernel (forget the GNU/Linux
> debate, we might be neither).
>
> The fact that a project gets 47 commits and 100 list posts a week
> doesn't mean that it is being security audited, or that security is
> any kind of serious consideration in how their workflow operates.
>
> I tend to be firmly in the camp that a package shouldn't be removed
> unless there is evidence of a serious bug (and that includes things
> blocking other Gentoo packages).  If somebody wants to come up with a
> "curated" overlay or some way of tagging packages that are considered
> extra-secure that would be a nice value-add, but routine auditing is
> not a guarantee we provide to our users.  The lack of such an audit
> should not be a reason to treeclean.

+1

>
> --
> Rich
>



-- 
アリス フェッラッシィ
Alice Ferrazzi

Gentoo,  If it moves, compile it!
My_overlay: https://github.com/aliceinwire/overlay
Gentoo Euscan: http://goo.gl/YNbU3h
Mail: Alice Ferrazzi 
PGP: 2E4E 0856 461C 0585 1336 F496 5621 A6B2 8638 781A

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

[Rich Freeman]

On Tue, Jan 3, 2017 at 9:57 AM, Michael Mol  wrote:
>
> 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.)
>

Are you suggesting that we should ban any package from the tree if we
don't have evidence of it having recently being subjected to a
security audit?  We might literally have 3 packages left in the tree
in that case, probably not including the kernel (forget the GNU/Linux
debate, we might be neither).

The fact that a project gets 47 commits and 100 list posts a week
doesn't mean that it is being security audited, or that security is
any kind of serious consideration in how their workflow operates.

I tend to be firmly in the camp that a package shouldn't be removed
unless there is evidence of a serious bug (and that includes things
blocking other Gentoo packages).  If somebody wants to come up with a
"curated" overlay or some way of tagging packages that are considered
extra-secure that would be a nice value-add, but routine auditing is
not a guarantee we provide to our users.  The lack of such an audit
should not be a reason to treeclean.

-- 
Rich

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

[M. J. Everitt]

On 03/01/17 14:57, 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?) 
Possibly this page may help:

https://wiki.gentoo.org/wiki/Project:Treecleaner/Policy

Also

https://wiki.gentoo.org/wiki/Project:Bug-cleaners

is quite enlightening [having burnt my fingers on those].



signature.asc
Description: OpenPGP digital signature

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

[Damien LEVAC]

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?

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

[Kristian Fiskerstrand]

On 01/03/2017 03:57 PM, Michael Mol wrote:
> 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.)

A distinction here likely needs to be made between actively maintained
upstream and actively Gentoo maintained as well. Actively maintained
upstream might not be an issue for a feature complete package, but if it
lacks a Gentoo-maintainer in addition it is worrying.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

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)
> >> 
> >> 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?) 

signature.asc
Description: This is a digitally signed message part.

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

[Damien LEVAC]

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 that either compromise security or 
affect normal usage subject to the condition that it is not still used 
by users. I do not think at this point in time Gentoo devs have any mean 
to know the popularity of different packages, but that would be a must 
to take proper decision as far as retiring packages goes.


-- Just a random Gentoo user.