[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] Reminder: ALLARCHES
From:       Jeroen Roovers <jer () gentoo ! org>
Date:       2016-05-03 21:34:36
Message-ID: 20160503233436.17837064 () wim ! fritz ! box
[Download RAW message or body]

On Sun, 1 May 2016 16:16:59 -0700
Daniel Campbell <zlg@gentoo.org> wrote:

> On 05/01/2016 07:03 AM, Andreas K. Huettel wrote:
> > Am Sonntag, 1. Mai 2016, 15:32:27 schrieb Jeroen Roovers:  
> >> On Sat, 30 Apr 2016 23:16:42 +0200  
> > 
> > (For the record, hppa is definitely NOT the problem.)
> >   
> Forgive me, I just pulled hppa out of the air as an example of a
> secondary, different arch. afaict nobody's really picking on a
> specific arch.

[Well, since we're trying to stay non-specific here and failing anyway,
I might as well add that HPPA currently has more than ten dozen open
stabilisation/keywording requests and that I find little time to
address them these days except for the bare necessities like security
keywording.]

The more generic problem is this. As I have said many times before,
doing generous sweeping stabilisations for obsolete architectures is
time-consuming and pointless. "One man and his magic script" is no cure
for our stabilisation efforts as you cannot expect any attention to
architecture specific details or environment in which those
architectures are used from a single person who hasn't even seen,
touched or smelled most of those architectures in hardware.

Consider that only few architectures may be considered "workstation
class", i.e. those you would nowadays use to develop/compile/test
software for other architectures on. Compared to ten or fifteen years
ago, few such architectures remain: Alpha, HPPA, MIPS and SPARC
workstations are fast becoming too slow, (open source) software no
longer supports their quirks, and keeping such basic modern day
workstation amenities as a browser alive for a specific architecture
requires a lot of love and still leaves open a huge performance gap
compared to x86, PowerPC and perhaps some of the faster ARM systems
(IA64 being in limbo). Packages are being "compile-tested" (whatever
that is) and branded "stable" while no-one actually makes sure keeping
those packages stable makes any sense. [I should know: HPPA runs a
stable Firefox that (with an ad blocker in place) takes a few _minutes_
to process the usual JavaScript attached to common web pages.]

In short, keeping the former workstation class architectures up to date
with workstation class packages (desktop environments, web browsers,
IDEs, wide support for scientific calculation, scripting languages, even
media players and professional audio sofware) is pointless, and yet the
evidence says that's exactly where the effort is going.

The solution is to have people with an actual interest in a specific
architecture determine whether stabilising a package is viable, and
taking sensible action, like dropping stable keywords where applicable.

Stabilising simply because maintainers need to clean up old ebuilds
simply prolongs the needless assignment of resources that will never be
used since we can already do this by running build systems on unstable
ebuilds without the need to make that distinction. Having ALLARCHES on
top of that means blindly stabilising for both obsolete and current
architectures, which actually adds on top of the existing problem and
creates new problems, like calling something "stable" that obviously
isn't because the label is applied without the QA.


     jer

[prev in list] [next in list] [prev in thread] [next in thread]