| 1 |
Hi! |
| 2 |
|
| 3 |
On Wed, 08 Jul 2015, Ciaran McCreesh wrote: |
| 4 |
> On Wed, 8 Jul 2015 20:07:34 +0200 |
| 5 |
> Tobias Klausmann <klausman@g.o> wrote: |
| 6 |
> > In essence, assuming we can "just scale" to make CI work is |
| 7 |
> > ignoring the matter of the slower archs. And I suspect the "it |
| 8 |
> > works on amd64, fuck everyone else" is not something we want to |
| 9 |
> > pick as a motto. |
| 10 |
> |
| 11 |
> "It works on amd64 on a clean build system" is a heck of a lot better |
| 12 |
> than "it may or may not work on one developer's heavily modified |
| 13 |
> box"... The point of testing is not to catch all problems. It's just |
| 14 |
> there to catch some simple screwups, cheaply. |
| 15 |
|
| 16 |
Agreed. Still, in my experience, problems that are not seen on |
| 17 |
amd64 are the vast majority of timesinks. Usually, by the time |
| 18 |
non-amd64 shows up on a non-security bug, the Basic Bullshit™ has |
| 19 |
been sorted. And even if it isn't: Arches are usually quick to |
| 20 |
point it out and the rest of arches move on to the next bug. The |
| 21 |
truly arch-dependent bugs are what wastes my time: |
| 22 |
|
| 23 |
For example: |
| 24 |
|
| 25 |
- dependencies not being keyworded for arch or ~arch but only |
| 26 |
amd64/~amd64 |
| 27 |
- dependencies not even building on ~arch, but on ~amd64 |
| 28 |
- package assuming availability of gcc/ghc/Python-X.Y when |
| 29 |
arch/~arch only has something for <Y or <X |
| 30 |
- my favourite: assuming udev is at version X for arch/~arch when |
| 31 |
it has been broken there for roughly twelve kernel versions due |
| 32 |
to udev/systemd upstream not caring. The information is one |
| 33 |
equery-y command line away, but no, let's file that bug. |
| 34 |
|
| 35 |
Having every arch team chase the deps for every package is very, |
| 36 |
very frustrating, since it is so trivial a problem. We need a |
| 37 |
tool that answers the question: "I want to mov cat/pkg-1.2.3 to |
| 38 |
stable for arches a, b and c, what do I need?" for _every |
| 39 |
package_. Some groups seem to have tooling for this, but it is |
| 40 |
far from easily (obviously?) available, so every team gets to |
| 41 |
re-discover dependency hell. Ruby is especially bad since |
| 42 |
FEATURES=test make the depgraph explode (and sometimes circular). |
| 43 |
|
| 44 |
Regards, |
| 45 |
Tobias |
| 46 |
|
| 47 |
|
| 48 |
-- |
| 49 |
Sent from aboard the Culture ship |
| 50 |
GSV (System Class) Empiricist |
Archives