On Wed, Jul 8, 2015 at 10:11 PM, Steev Klimaszewski <st...@gentoo.org> wrote:
> On Wed, 2015-07-08 at 21:11 +0200, Tobias Klausmann wrote: > > 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. > > > > That's a failing of the arch team or the committer then - or whomever > keyworded the package without testing the dependencies. That's why the > keywording bugs happen when dependencies change - and yes, occasionally > a dependency loses it's keywords and that may be where the issue comes > from, I'm not sure. This used to be watched very closely, but I believe > the tool being used broke at some point. > > What exactly do you mean, it's just one command line away but let's file > the bug - yes a bug SHOULD be filed, so that the people know of the > issue so it doesn't get repeated, over and over. > > > > 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 > > > > > > The only fear I have about CI, is that we turn into every other distro > out there where "it builds, ship it!" - I know I prefer to have our arm > team actually test the packages more than just doing FEATURES=test > (assuming the tests aren't broken on arm) emerge, although I know there > are some people on the team who feel that it's too much to actually test > all of the arm boards. For a long time, certain binary distros were > compiling anything and everything, and if it built for other arches it > was available. Even if there was no way it would possibly work on that > arch. > > So don't keyword or stabilize packages you don't test thoroughly. I see how CI *could* be used to do bad things; but I don't see anyone proposing it be used in that way; nor do you have to accept such suggestions (its your arch, after all.) -A > Regards, > Steev > > >
