Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan & schedule

[Alec Warner]

On Wed, Jul 8, 2015 at 10:11 PM, Steev Klimaszewski <steev@g.o>
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 <klausman@g.o> 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
>
>
>