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.
Well that should be it. I hope to achieve at least part of this and work on some ideas regardless of being elected :-)