So you want me for council? – kinda manifesto

Looks like I was nominated for the council this year. It is quite tough decision for me wether to run for council again or not. Well to cut this summary short in the end I should have enough time if nothing special happens during the year and decided to try.

Lets take look on what are my ideas and why I should obtain dev votes (apart from that I already was in council and did not screw up too much) :-)

Stability and reliabilty

Most of the guys probably already noticed, but once again I have to say that I run stable tree. With this I have to say most developers treat stable tree as something ugly. This means that fixes get to the testing but never or always late to the stable.

I consider stable rolling-updates tree to be our main advantage over any other distro but the key here is to make it reliable and working. When I did the clean hardened install I ended up keywording lots of apps in order to make it work. Now the situation is better I hope. As I stable everything I need or packages which do not work up to my requirements, but still I want to work up some way how to make the stable our primary target (not that all devs should run stable, but stable should be around for our users and testing should be around for testers not final deployments).

We have many guys working in this area lately which also make things look shinier. Ago is stabling almost instantly insane amounts of packages (burnout candidate YAY :-P), Paweł is running automated scripts (slightly controversal and I consider it still buggy and in its infant stages) that open stable bugs for mature enough software.

Furthermore I would like to put more work on poor arch testers (not all archs just first one who gets there probably) to actually check and clean ebuilds from cruft. Often when I was stabling stuff from not-well-handled category I ended up mostly redoing the ebuild to clear all the stuff (mostly the changes were trivial but benefitical in longer run) when commiting the stable keyword, resulting in better working ebuild in stable.

Last point for stabilisations is the current tool (bugzilla) is damn ineffective. But there won’t be any solution for that from me, I think there are more fit guys for this in our AT teams to find out solution for this.

Community involvement / getting the edge

On the other hand Gentoo is (and always was) about RICING. Without -OZOMGFAST in CFLAGS are our lifes more dull and gray.

We need more developers that is a real point. 250+- guys can’t manage the amount of ebuilds we have in good shape. We designed lots of automated tools to make our lifes easier but still it is not handling the growing numbers of packages in the tree.

With the git migration done (see point bellow) we should be in great&easy position to adapt new contributors whom do not even need developer status. They just need to use git commit and git format-patch to give us their improvements.

From my experience within Libreoffice comunity the model where users just mail their fixes to ml where they are sorted out and wether asked for improvements or merged to master (our case of testing tree) right away.

This should ensure proper ricing for everyone while with the AT stabilisation testing we should get proper testing and more ensuring testing.

Some people might say that we already have overlays, but I think they are cool for development of features, but not for simple fixes or just plain version bumps. Note that updating major piece of ponies like KDE requires overlay because each version is broken in its own and unique way ;-).


This must be on each manifesto :P Anyway this year it seems to happen regardless on what I do. We only lack the working git-svn with subversion-1.7.

So I expect myself to kick Theo to give me sitrep here and there to see it actually happen. I can be really annoying and he is really tiny.

Reducing supported arch targets

This point gets back to the stable one. With current bugzilla one can see that some arches take 1 year or so to stabilise some packages. This is more than suboptimal… I think we should start working on deciding which platforms we want to actually provide stable packages and which are running out and actually dying (ie is there and ppc32 hw sold in last 5 years).

This should reduce the time to finish stabilisation and make the main tree more up-to-date and slimer.

Final word

Well that should be it. I hope to achieve at least part of this and work on some ideas regardless of being elected :-)

Bookmark the permalink.

8 Responses to So you want me for council? – kinda manifesto

  1. Ben de Groot says:

    I support this message.

  2. Teika kazura says:

    Gentoo is the sole stable and flexible distro. In other stable distros (read: Debian), you can’t deviate from the official (you can, but soon it’ll be a BIG BIG mess), while other distros are simply broken. I’ve been thinking of getting out of Gentoo for years, but I’m still here.

    Thanks Scarabeus for your manifesto.

  3. tclover says:

    I have already voted for you, even if, I am not a dev ;-).

    • scarabeus says:

      We shall see what dev guys want :-)
      Also easiest way how to get to vote is to became dev. Interested? :-P

      • tclover says:

        I’d like to get my hand on C if I could get myself to do it. So no for now.

        I’d like to see that git migration sonner than later. If it depended on me I’d have already made the migration and composed with what could possibly happen because certainly issues await the after migration.

  4. durandal says:

    I hope obscure arches remain supported at least at a best-effort level. Those of us willing to figure out and stick with odd hardware can deal with the easy stuff ourselves, but a little developer support on the core system goes a long way too =).

    I think dropping the stable keyword in favor of ~testing on arches other than x86 and amd64 (and perhaps x32 in 6-12 months) would ease developer workload and improve user experience on those less common arches.

    I have used Gentoo with PPC32, PPC64, SPARC, and various ARM subarches, and I judge that none of them receives enough testing/feedback to justify the stable label or a distinction between stable and unstable except perhaps for @system packages.

    • scarabeus says:

      Yeah, I have on my mind something like that.
      I also have access to ppc/ppc64 now and tried to stable here and there (libreoffice and packages I usually maintain) so I don’t lag too much behind and don’t have to provide users at least something bit fresh.

      But basically it is better to not pretend that stable is maintained enough for such arches and just revert to testing.
      For example when I tried desktop profile on ppc32b first time it was not even possible to merge the default set with kde enabled due to some missing stables.

      • durandal says:

        I’ve thought more about this, and I have a more drastic proposal:
        * Introduce a new keyword to partially replace ppc[64], sparc[64], mips[64], arm[64] (soon =), hppa[64], sh, alpha, and whatever else. I’ll call it ‘other’, but there may well be a better name.
        * [~]x86|amd64 keywording policy is not changed.
        * Binary-only (www-plugins/adobe-flash), asm-only (dev-lang/v8), and platform hardware-specific (sys-boot/yaboot) packages get specific keywords and don’t get ‘other’ (just like today). For example: dev-lang/v8 gets x86, amd64, mips, and arm, and sys-boot/yaboot gets ppc and ppc64.
        * All other packages get the ‘other’ keyword once they’ve been tested successfully on any of the ‘other’ arches.
        * Users of e.g. PPC64 use ACCEPT_KEYWORDS=”ppc64 other”.

        The rationale is that most portability problems on non-x86 arches are due to either:
        * binary distribution or asm routines with no fallback (we do a good job with these already via -*) or
        * some upstream developer who only tests on x86 and amd64 and has either a crappy build system or bad assumptions (e.g. pages are always 4k).

        As a PPC64 user, I assume that if it built on SPARC for somebody and it’s not SPARC-only (i.e. sys-boot/silo), it must be pretty portable. This isn’t always true, but I expect it to be better overall than having to add dozens of perfectly portable packages to package.accept_keywords.