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

[Tobias Klausmann]

Hi! 

This got a bit rambly, sorry 'bout that.

tl;dr: Continuous Integration is a neat idea if you have the
Hardware. The off-mainstream arch teams don't.


On Tue, 07 Jul 2015, Ciaran McCreesh wrote:
> On Tue, 07 Jul 2015 08:04:47 +0800
> Patrick Lauer <patrick@g.o> wrote:
> > I'll laugh about it next time I update OpenFOAM:
> >
> > Fri Jun 27 12:52:19 2014 >>> sci-libs/openfoam-2.3.0
> >        merge time: 1 hour, 5 minutes and 8 seconds.
> > or
> >
> > Sun Jun 29 20:36:09 2014 >>> sci-mathematics/nusmv-2.5.4
> >        merge time: 2 hours, 58 minutes.
>
> What's the problem? Better the build bot wastes that time once than a
> whole bunch of users do.

Just be aware that that Just Won't Happen for the off-mainstream
archs. We just don't have the hardware to keep up with something
like that. Unless you want to employ several people reordering
the CI checks so a test for glibc doesn't make mutt, util-linux,
iptables and 55 other packages wait for hours.

'Cause invariably, if the CI system is delayed beyond the
expectation for the package itself, it will be ignored.

It would also mean that the other purposes the devboxes are used
for will be delayed non-trivially. In the case of Alpha, that
would for example be upstream gcc testing, and stage3 building. I
am sure arches like PPC64, IA64 and so on have the same problem.

> > That's without dependencies, so from a clean minimal starting point
> > (once you figure out what useflags are needed) you're looking at 12+
> > hours of walltime to get that checked. (On a reasonably modern Xeon
> > with SSDs ...)
>
> Uh, no, because you use binary packages for the dependencies, and you
> use a package mangler that can figure out the use flags for you.

Even with binary package usage (which is not as efficient as it
could be due to USE flags), testing Qt4 (as in compile it and run
the test suite, which is the bare minimum) took me close to 10
hours the other day. Not including fixing fetch problems halfway
through. During this time, very little else got done on the one
devbox we have.

> > So thanks for your intentional comedy, but let's be serious here.
>
> Exherbo's been doing all this for years, and it works rather well. The
> only comedy is that Gentoo doesn't even realise this is trivial to do
> nowadays.

Exherbo is not supporting as many off-mainstream architectures as
we do, so the comparison is flawed at best. Yes, sure, let's run
CI for amd64 and maybe x86 and whoever else has the hardware. But
it will not speed up stabilization bugs regarding the long tail.
It might even lead to people completely ignoring the slow
architectures and the rift between amd64 and the rest becoming
yet wider.

Don't get me wrong, abandoning Alpha and other architectures is
an option, but remember that for some of these, we are the last
distro that still provides install media and a decent (as in:
current and complete-ish) set of packages. The very fact that we
are able to let amd64 and the rest drift a bit is the reason why
we can still pull it off.

I have considered dropping Alpha entirely (for myself, that is;
I'd resign as the arch team lead and stop working on it; the
devbox, which is soft-donated through me, would stay available).
But I would rather not, for various reasons, none of which are
technical. Then again, I'm not a Gentoo dev because it makes
sense rationally (it does, but it's not my reason).

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.

Regards,
Tobias`



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