Gentoo Archives: gentoo-dev

From: Ultrabug <ultrabug@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp
Date: Tue, 09 May 2017 13:48:00
Message-Id: 361ffedd-3f3c-1c23-c5fe-99dc50808a5a@gentoo.org
In Reply to: Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp by "Michał Górny"
1 -----BEGIN PGP SIGNED MESSAGE-----
2 Hash: SHA256
3
4 On 08/05/2017 15:49, Michał Górny wrote:
5 > Dnia 8 maja 2017 15:27:18 CEST, Dirkjan Ochtman <djc@g.o>
6 > napisał(a):
7 >> On Mon, May 8, 2017 at 12:49 PM, Mikle Kolyada
8 >> <zlogene@g.o> wrote:
9 >>> Against. Do not touch things you are not working on, council
10 >>> has
11 >> already
12 >>> dropped m68k s390 and sh to exp few years ago. Now we have a
13 >>> big mess there and only, while ia64 sparc and co have slow but
14 >>> progress and mature enough stable profiles.
15 >>
16 >> Obviously we should prevent big messes from happening. But it's
17 >> a mistake that things I don't work on don't affect me -- work
18 >> left over by lagging arch teams can affect me in many ways, in
19 >> terms of having to keep older versions of my packages working and
20 >> in the tree, and having to keep track of many more KEYWORDREQs
21 >> and STABLEREQs.
22 >>
23 >> To me it's likely that the pace of stabilization for everyone is
24 >> affected by the slower arches, in the sense that maintainers are
25 >> less likely to stabilize newer versions if they see that arches
26 >> can't keep up with previous requests. This means that even stable
27 >> amd64 users are affected to some extent by ppc being slow to
28 >> stabilize.
29 >
30 > Plus the usual mess of having to keep up with multiple large
31 > stablereqs for stuff where we need to stabilize newer while some
32 > arches are still two stabilizations behind.
33 >
34 > Not to mention when we want to stabilize a new version but the
35 > arches still haven't even keyworded it...
36
37 That !
38
39 We can all face that our latency is not good for our traction on a
40 wider user base.
41
42 Freeing ourselves from this kind of latency is energy saving and thus
43 a positive move imho.
44
45 >
46 >>
47 >> Cheers,
48 >>
49 >> Dirkjan
50 >
51 >
52 -----BEGIN PGP SIGNATURE-----
53
54 iHUEAREIAB0WIQSqwxDKv5211qJQBiIqJBJLtlj6EwUCWRHIfQAKCRAqJBJLtlj6
55 EwmzAPwP2a6MgG3aE6EdSuPLjsabytT+qRskanNMJtiVsQqWpwD+NsGzWk9ff1RS
56 2mZYazWC5U9HBD3MzPG65jhX8Dl43jA=
57 =h+5a
58 -----END PGP SIGNATURE-----