On Sun, 16 Feb 2014 09:03:31 -0500
Rich Freeman <[email protected]> wrote:
> Well, that depends on your perspective. If they fix them by deleting
> the old version, then whether they've made things better or worse is a
> matter of philosophy.
When you've cut the understaffed arch team out of the loop and removed
the troublesome old ebuild, things are actually better.
The problem with any arch team is that they may have ideas about what
should be available in the stable branch that might not match what they
can nowadays realistically maintain. This might be because fewer people
use that architecture than did in the past, or it might be because the
best systems using that architecture have become too slow for modern
versions of some software, or because a one time arch developer
happened to like certain packages and at the time thought it was a nice
idea to mark X packages stable there.
We've seen problems like this in the past with the bigger desktop
environments being stable (but lagging) on typical workstation
architectures, for instance, and also with expansive server application
frameworks on typical server architectures.
> That's basically the counter-argument to removing old versions. If
> the newer version doesn't work at all, then the old buggy version is
> superior. It is better to have the bugs ignored, than to pester the
> maintainer until the package is disabled entirely.
>
> Honestly, this whole conversation seems rather theoretical.
Would you like some examples to be able to move beyond the theoretical?
I have plenty.
> What I haven't heard from is the minor arch leads. Actually,
> looking at the base project page, it seems like half of them don't
> even have leads.
That's what "understaffed" means. I guess for them to engage in this
discussion would take away even more precious time. :)
> The other issue is that at least some devs have been stabilizing new
> packages on minor archs for which the council decided to drop stable
> keywords. How to handle that is on the next agenda as well.
Why is this a problem? Also, doesn't profiles.desc already handle this?
> Basically all of this boils down to whether it is a good compromise to
> redefine "stable" to something different on minor archs so that they
> can make some use of the keyword, and do it without driving
> maintainers nuts. I don't have a big problem with that, as long as it
> is done in a way that doesn't place any burden on anybody who doesn't
> use the minor arch (including bug wranglers, maintainers, etc).
What does that mean? "Stable" should mean the same for everyone, as
should "unstable" and "not keyworded". It sends a very clear message to
whomever would like to use a certain ebuild on a certain architecture.
jer
