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----- |