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

[Tobias Klausmann]

Hi! 

On Thu, 09 Jul 2015, Steev Klimaszewski wrote:
> On Wed, 2015-07-08 at 21:11 +0200, Tobias Klausmann wrote:
> > 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.

What I meant is when I get a stabilization bug for
cat-egory/foo-1.2.3 which depends on >=other-cat/bar-1.0.5. The
latter is amd64 but not alpha or ~alpha. And it, in turn, has yet
more deps in the same vein. Now I have several options:

1/ Pull in all dependencies and test them. This may mean I have
   to let the deps soak in ~alpha for 30 days, leading the
   original dev to complain that the arches are slow.
2/ Try and figure out if I can mask a USE flag on foo-1.2.3 that
   avoids the dependency. If there isn't I can try and make one,
   which leads into another hell of dep chasing for revdeps of
   foo-1.2.3.
3/ Complain on the bug that the maintainer of foo-1.2.3 should
   figure out the deptrees before CCing arches.
4/ Opt out of stabilization for foo-1.2.3

If it turns out that bar-1.0.5 or one of its deps breaks a
completely unrelated package, I get to revert all of this until a
fix is found. And then do it all over again.

What instead should happen:

The maintainer of cat-egory/foo sees that 1.2.3 has a new dep,
which is >=other-cat/bar-1.0.5. A quick check with equery* shows
that it isn't stable/keyworded for alpha and hppa.

Thus, the maintainer files a bug for bar-1.0.5 to be stable on
alpha and hppa, possibly/ideally checking with bar's maintainer.
The stabilization for foo-1.2.3 on amd64 can continue, just don't
CC alpha and hppa yet.

Once bar-1.0.5 is stable (or alpha/hppa have opted out), CC them
on the foo-1.2.3 bug.

*(An alternative is to add all the keywords you want and run
  repoman full. Just don't accidentally commit that edit.)

The bad case (ignoring the non-amd64 deptree) is not the
majority, but it's a very frustrating and time consuming
experience for archtesters. Often, the deptrees for the minor
archs are broken in subtly different ways, resulting in the time
wasting to be multiplied.

Option #3 above I have shied away from, since it would feel sort
of aggressive, pedantic and picky when that is not really in my
nature. If everyone is okay(ish) with it, I'll start doing it.

> > 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).
>
> 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.

We're already partway down that road of IC,SI. For Alpha, it's
not because we don't want to, but rather because we know that if
we do it 100% properly, we will quickly fall even further behind.
I guess we do speculative testing: If it compiles+tests, great.
If the package actually breaks, a user will surely tell us.


Yes, CI is nice to have if you have the hardware to do it. But if
parts of our workflow start depending on it, we will quickly lose
the minor archs.

Regards,
Tobias

-- 
prom_printf("No VAC. Get some bucks and buy a real computer.");
	linux-2.6.19/arch/sparc/mm/sun4c.c