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

[Alec Warner <antarus@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 5122 bytes --]

On Thu, Jan 5, 2017 at 8:27 PM, Kent Fredric <kentnl@gentoo.org> wrote:

> On Tue, 3 Jan 2017 10:23:02 -0500
> Rich Freeman <rich0@gentoo.org> 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
> users of problems they might face, allowing them to contravene the hard
> masks if they're feeling like they want to be adults.

[-- Attachment #2: Type: text/html, Size: 6730 bytes --]