Hi! 

On Wed, 08 Jul 2015, Ciaran McCreesh wrote:
> On Wed, 8 Jul 2015 20:07:34 +0200
> Tobias Klausmann <klaus...@gentoo.org> wrote:
> > In essence, assuming we can "just scale" to make CI work is
> > ignoring the matter of the slower archs. And I suspect the "it
> > works on amd64, fuck everyone else" is not something we want to
> > pick as a motto.
> 
> "It works on amd64 on a clean build system" is a heck of a lot better
> than "it may or may not work on one developer's heavily modified
> box"... The point of testing is not to catch all problems. It's just
> there to catch some simple screwups, cheaply.

Agreed. Still, in my experience, problems that are not seen on
amd64 are the vast majority of timesinks. Usually, by the time
non-amd64 shows up on a non-security bug, the Basic Bullshitâ„¢ has
been sorted. And even if it isn't: Arches are usually quick to
point it out and the rest of arches move on to the next bug. The
truly arch-dependent bugs are what wastes my time:

For example:

- dependencies not being keyworded for arch or ~arch but only
  amd64/~amd64
- dependencies not even building on ~arch, but on ~amd64
- package assuming availability of gcc/ghc/Python-X.Y when
  arch/~arch only has something for <Y or <X
- my favourite: assuming udev is at version X for arch/~arch when
  it has been broken there for roughly twelve kernel versions due
  to udev/systemd upstream not caring. The information is one
  equery-y command line away, but no, let's file that bug.

Having every arch team chase the deps for every package is very,
very frustrating, since it is so trivial a problem. We need a
tool that answers the question: "I want to mov cat/pkg-1.2.3 to
stable for arches a, b and c, what do I need?" for _every
package_. Some groups seem to have tooling for this, but it is
far from easily (obviously?) available, so every team gets to
re-discover dependency hell. Ruby is especially bad since
FEATURES=test make the depgraph explode (and sometimes circular).

Regards,
Tobias


-- 
Sent from aboard the Culture ship
        GSV (System Class) Empiricist

Reply via email to