On Sat, Jan 17, 2015 at 12:35 PM, Patrick Lauer <[email protected]> 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
