I know it’s not even spring yet, and we can’t even be sure if Gentoo is gonna be on Google Summer of Code this year, but maybe if we start early, if/when Gentoo is accepted into Summer of Code we’ll have already some ideas to throw to our users.
To begin with, I think we should decide, this year, to limit ourselves to projects that affect Gentoo as a whole project, and avoid using up slots for external projects. Although as Grant said we have external projects affecting the core of Gentoo, I think they should be left independent as they are, and we should focus on stuff that is still done in-house, and need to be improved. It doesn’t matter if the project is pkgcore, paludis or even OpenRC: if they are external, they remain external, Gentoo has enough internal projects to complete.
So here are a few suggestions that might be worth discussing:
- sandbox: since Martin (azarah) has been busy and then was retired, there was nobody working full-time on sandbox, yet it’s one of the core utilities that Gentoo uses; Martin left an experimental branch of sandbox, with the code used for Gentoo/FreeBSD support in it, stale there, at the moment that sandbox fails badly with Linux modules, as the forward port of the fix for the issue with recent kernels from the old version is non-trivial; having someone to cleanup sandbox code and finish the 1.2.20 release would be quite good;
- autoepatch: this is something I left dangling myself; autoepatch was supposed to be a way to replace gnuconfig.eclass and elibtoolize, by being able to apply common patches and fixes to source code after unpack and before compile phase; this way it would be possible to fix common mistakes in source code, like broken autotools and similar, without having to handle everything ebuild-per-ebuild; a few posts about autoepatch are available here ;
- eselect gcc: we all shudder to think about the brokenness caused by eselect compiler; it was certainly not the way to go; but eselect is being used more and more in Gentoo lately, so it would make sense to reimplement gcc-config and binutils-config as eselect modules in a 100% compatible way, not like eselect compiler (whih changed the format of the data files and so on).
- more eselect modules: whois, tar, cpio, sendmail, there are many packages that have implementations compatible enough to be runtime-swappable; it would be nice to have an easy way of selecting between them, without having to write one extra module for everyone of them; something like Debian’s alternatives would be nice, I think; yes I do know that for sendmail there should be mailwrapper, but it’s at least two years it’s in package.mask if I recall correctly; it’s either time to unleash it or to reimplement it;
- multilib implementation okay this is asking too much, but it would be nice to see someone starting to work on that, in my opinion;
- support for user-defined extraction tools this way the user might just decide to use libarchive’s bsdtar command for extracting zip files, and the get rid of unzip; I doubt it’s an easy thing to do, but, well, it might be doable.
These are just a few ideas I gathered thinking about the next Summer of Code. Probably other developers working in other areas might find more of these, which don’t relate to external projects, and are just Gentoo’s.
At any rate, people, if you have proposals for SoC, start talking already, it’s better to start too soon rather than too late!