Re: [gentoo-dev] Things one could be upset about

[Dirkjan Ochtman]

On Sat, Jan 17, 2015 at 12:35 PM, Patrick Lauer <patrick@g.o> wrote:
> In no way exhaustive list, feel free to remember a dozen things I forgot ;)
> (If you suggest other things please try to offer constructive criticism,
> i.e. possible strategies to fix issues ... whining by itself is not very
> useful)

I think this is a good list, thanks for coming up with it. I very much
agree that whining by itself is not very useful, and we should find
ways to move things forward (even if sometimes it's not the most
straightforward way?).

> * AutoRepoman catches on average maybe 2 user-visible breakages.
>     Mostly removing stable on HPPA ;)
>     Fix: Make repoman faster (tree-wide scans take ~2 CPU-hours)
>     Fix: Remind people that using repoman is not optional
>
> * AutoRepoman catches issues, but no one but me seems to care
>     Fix: Remind people of http://packages.gentooexperimental.org/repoman-current-issues.txt
>     Fix: Make it yell louder? It currently reports on IRC to #gentoo-{bugs,qa}

I'll happily fix my repoman issues when I notice them. I try to always
run repoman full on a package, but like you say, a tree-wide scan
isn't really viable on a per-commit basis. Can we have AutoRepoman
report open issues to gentoo-dev on a weekly basis? That seems like a
fine idea to me. Per-maintainer and per-team/project/herd RSS/Atom
feeds would also be pretty nice to have.

Also, I hate something like
"['dev-python/restkit[python_targets_python2_7(-)?,-python_single_target_python2_7(-)]']".
What the hell kind of warning is that? I guess maybe these are the
results of USE_EXPAND trickery and what not, but it would sure be nice
to have something more readable.

> * Portage is too slow
>     On 'small' hardware emerge -upNDv @world can take enough time
>     to make updates prohibitive - on an 800Mhz machine it took me
>     about 3 days to figure out a solution to some silly blockers due to the
>     very slow change test cycle
>     Fix: Do some profiling and un-refactoring to remove useless code
>     Fix: Set up a reference system (CI) to catch future regressions

Why not use paludis, or another package manager?

> * Stage3 archives are too fat
>     See https://bugs.gentoo.org/show_bug.cgi?id=531632
>     We're now shipping three python versions and glib for extra fun!
>     Fix: Motivate releng to stop being silly

Why the heck do we ship both 3.3 and 3.4? I forget the exact situation
with 2.x and 3.x, but I don't think setting PYTHON_TARGETS to 2.7-only
is a great option if that remains the default after installation
(although it would be fine for just the initial stages).

> * AutoRepoman still runs on my hardware
>     Fix: Remind infra of https://bugs.gentoo.org/show_bug.cgi?id=484064
>
> * euscan doesn't run on infra hardware
>     Fix: https://bugs.gentoo.org/show_bug.cgi?id=453886
>
> * mail archives have been broken since 2012
>     Fix: get infra to either fix it, or provide enough information that it can
>     be fixed. See https://bugs.gentoo.org/show_bug.cgi?id=424647#c27
>
> * libreoffice-bin isn't built on infra hardware
>     Fix: Remind infra to set up a build environment for that

These ones, the euscan one in particular, also have been stuff I cared
about, but after trying a bunch of times to start helping infra out,
apparently they don't have any ways to absorb new contributors. This
does seem like a big problem given the amount of technical debt on the
infra-side you're laying out here.

I understand that it's a big job and that there are security aspects
to it, but if there are no ways to empower new people to help them
out, that is worrying to me.

> * Some stable bugs are left alone for months
>    See e.g. https://bugs.gentoo.org/show_bug.cgi?id=485632
>    Fix: Have more people work on stable bugs
>    Fix: Motivate people to file more stable bugs (continuous updates)

This is a thorny problem as well. I worry that we lose momentum here
due to size and perfectionism (e.g. we can only stable new gcc once we
fix all the blockers, and we don't have enough active maintainers on
some of those blockers). I think we should maybe stabilize more
optimistically at least on common architectures, e.g. by having a
lighter-weight upfront testing process and relying more on maintainers
keeping up to speed on subsequent bugs.

I also wonder if we could sort of crowd-source archtesting, maybe by
having people contribute their package.keywords through gentoo-stats
or some such to see how well an unstable package is being tested on
stable systems already.

Or if we should have a different process for e.g. Python/Ruby/Perl/PHP
packages compared to C/C++ packages, since the former are much less
sensitive to architecture differences.

Also, one thing you didn't mention is the git migration; I think our
usage of CVS definitely counts as a big gob of technical debt. What's
that currently blocked on, anyway?

Cheers,

Dirkjan