| 1 |
On Wed, 2015-07-08 at 21:11 +0200, Tobias Klausmann wrote: |
| 2 |
> Hi! |
| 3 |
> |
| 4 |
> On Wed, 08 Jul 2015, Ciaran McCreesh wrote: |
| 5 |
> > On Wed, 8 Jul 2015 20:07:34 +0200 |
| 6 |
> > Tobias Klausmann <klausman@g.o> wrote: |
| 7 |
> > > In essence, assuming we can "just scale" to make CI work is |
| 8 |
> > > ignoring the matter of the slower archs. And I suspect the "it |
| 9 |
> > > works on amd64, fuck everyone else" is not something we want to |
| 10 |
> > > pick as a motto. |
| 11 |
> > |
| 12 |
> > "It works on amd64 on a clean build system" is a heck of a lot better |
| 13 |
> > than "it may or may not work on one developer's heavily modified |
| 14 |
> > box"... The point of testing is not to catch all problems. It's just |
| 15 |
> > there to catch some simple screwups, cheaply. |
| 16 |
> |
| 17 |
> Agreed. Still, in my experience, problems that are not seen on |
| 18 |
> amd64 are the vast majority of timesinks. Usually, by the time |
| 19 |
> non-amd64 shows up on a non-security bug, the Basic Bullshit™ has |
| 20 |
> been sorted. And even if it isn't: Arches are usually quick to |
| 21 |
> point it out and the rest of arches move on to the next bug. The |
| 22 |
> truly arch-dependent bugs are what wastes my time: |
| 23 |
> |
| 24 |
> For example: |
| 25 |
> |
| 26 |
> - dependencies not being keyworded for arch or ~arch but only |
| 27 |
> amd64/~amd64 |
| 28 |
> - dependencies not even building on ~arch, but on ~amd64 |
| 29 |
> - package assuming availability of gcc/ghc/Python-X.Y when |
| 30 |
> arch/~arch only has something for <Y or <X |
| 31 |
> - my favourite: assuming udev is at version X for arch/~arch when |
| 32 |
> it has been broken there for roughly twelve kernel versions due |
| 33 |
> to udev/systemd upstream not caring. The information is one |
| 34 |
> equery-y command line away, but no, let's file that bug. |
| 35 |
> |
| 36 |
|
| 37 |
That's a failing of the arch team or the committer then - or whomever |
| 38 |
keyworded the package without testing the dependencies. That's why the |
| 39 |
keywording bugs happen when dependencies change - and yes, occasionally |
| 40 |
a dependency loses it's keywords and that may be where the issue comes |
| 41 |
from, I'm not sure. This used to be watched very closely, but I believe |
| 42 |
the tool being used broke at some point. |
| 43 |
|
| 44 |
What exactly do you mean, it's just one command line away but let's file |
| 45 |
the bug - yes a bug SHOULD be filed, so that the people know of the |
| 46 |
issue so it doesn't get repeated, over and over. |
| 47 |
|
| 48 |
|
| 49 |
> Having every arch team chase the deps for every package is very, |
| 50 |
> very frustrating, since it is so trivial a problem. We need a |
| 51 |
> tool that answers the question: "I want to mov cat/pkg-1.2.3 to |
| 52 |
> stable for arches a, b and c, what do I need?" for _every |
| 53 |
> package_. Some groups seem to have tooling for this, but it is |
| 54 |
> far from easily (obviously?) available, so every team gets to |
| 55 |
> re-discover dependency hell. Ruby is especially bad since |
| 56 |
> FEATURES=test make the depgraph explode (and sometimes circular). |
| 57 |
> |
| 58 |
> Regards, |
| 59 |
> Tobias |
| 60 |
> |
| 61 |
> |
| 62 |
|
| 63 |
The only fear I have about CI, is that we turn into every other distro |
| 64 |
out there where "it builds, ship it!" - I know I prefer to have our arm |
| 65 |
team actually test the packages more than just doing FEATURES=test |
| 66 |
(assuming the tests aren't broken on arm) emerge, although I know there |
| 67 |
are some people on the team who feel that it's too much to actually test |
| 68 |
all of the arm boards. For a long time, certain binary distros were |
| 69 |
compiling anything and everything, and if it built for other arches it |
| 70 |
was available. Even if there was no way it would possibly work on that |
| 71 |
arch. |
| 72 |
|
| 73 |
Regards, |
| 74 |
Steev |
Archives