1 |
On Sun, 1 May 2016 16:16:59 -0700 |
2 |
Daniel Campbell <zlg@g.o> wrote: |
3 |
|
4 |
> On 05/01/2016 07:03 AM, Andreas K. Huettel wrote: |
5 |
> > Am Sonntag, 1. Mai 2016, 15:32:27 schrieb Jeroen Roovers: |
6 |
> >> On Sat, 30 Apr 2016 23:16:42 +0200 |
7 |
> > |
8 |
> > (For the record, hppa is definitely NOT the problem.) |
9 |
> > |
10 |
> Forgive me, I just pulled hppa out of the air as an example of a |
11 |
> secondary, different arch. afaict nobody's really picking on a |
12 |
> specific arch. |
13 |
|
14 |
[Well, since we're trying to stay non-specific here and failing anyway, |
15 |
I might as well add that HPPA currently has more than ten dozen open |
16 |
stabilisation/keywording requests and that I find little time to |
17 |
address them these days except for the bare necessities like security |
18 |
keywording.] |
19 |
|
20 |
The more generic problem is this. As I have said many times before, |
21 |
doing generous sweeping stabilisations for obsolete architectures is |
22 |
time-consuming and pointless. "One man and his magic script" is no cure |
23 |
for our stabilisation efforts as you cannot expect any attention to |
24 |
architecture specific details or environment in which those |
25 |
architectures are used from a single person who hasn't even seen, |
26 |
touched or smelled most of those architectures in hardware. |
27 |
|
28 |
Consider that only few architectures may be considered "workstation |
29 |
class", i.e. those you would nowadays use to develop/compile/test |
30 |
software for other architectures on. Compared to ten or fifteen years |
31 |
ago, few such architectures remain: Alpha, HPPA, MIPS and SPARC |
32 |
workstations are fast becoming too slow, (open source) software no |
33 |
longer supports their quirks, and keeping such basic modern day |
34 |
workstation amenities as a browser alive for a specific architecture |
35 |
requires a lot of love and still leaves open a huge performance gap |
36 |
compared to x86, PowerPC and perhaps some of the faster ARM systems |
37 |
(IA64 being in limbo). Packages are being "compile-tested" (whatever |
38 |
that is) and branded "stable" while no-one actually makes sure keeping |
39 |
those packages stable makes any sense. [I should know: HPPA runs a |
40 |
stable Firefox that (with an ad blocker in place) takes a few _minutes_ |
41 |
to process the usual JavaScript attached to common web pages.] |
42 |
|
43 |
In short, keeping the former workstation class architectures up to date |
44 |
with workstation class packages (desktop environments, web browsers, |
45 |
IDEs, wide support for scientific calculation, scripting languages, even |
46 |
media players and professional audio sofware) is pointless, and yet the |
47 |
evidence says that's exactly where the effort is going. |
48 |
|
49 |
The solution is to have people with an actual interest in a specific |
50 |
architecture determine whether stabilising a package is viable, and |
51 |
taking sensible action, like dropping stable keywords where applicable. |
52 |
|
53 |
Stabilising simply because maintainers need to clean up old ebuilds |
54 |
simply prolongs the needless assignment of resources that will never be |
55 |
used since we can already do this by running build systems on unstable |
56 |
ebuilds without the need to make that distinction. Having ALLARCHES on |
57 |
top of that means blindly stabilising for both obsolete and current |
58 |
architectures, which actually adds on top of the existing problem and |
59 |
creates new problems, like calling something "stable" that obviously |
60 |
isn't because the label is applied without the QA. |
61 |
|
62 |
|
63 |
jer |