Gentoo’s quality assurance is a quite difficult task to keep running smoothly: there are problems at so many levels that it’s not funny at all. I’ve been doing my share of the work, both with the tinderbox effort and with manual work to fix the issues when they come up. But there are some particular soft spots that I guess should be addressed sooner rather than later.
One of the most annoying problems I’m having lately is related to test failures with Python modules. Part of the failures were “expected” since they tied into the presence of Python 3.1 (I don’t use it on my standard system since it’s pointless to me but it’s available in the tinderbox), some were caused by GCC 4.4 and breaking of strict aliasing rules, others I’ve got no clue at all. Arfrerver cannot seem to reproduce them, and I don’t know how to look deeper into them. Having no idea where to start to find the cause of the failures, it also means that for me the problems are not solved.
But before somebody read something for Ruby and against Python in the fact that I have reported one if at all failure with Ruby packages’ tests, you should probably remember that we’re not running tests for any of the Ruby gems. Thankfully, as Alex posted yesterday are now being reviewed and added to the main Portage tree, and as we’re going to move to the fakegem eclass we’re also going to add the tests for all the packages. This is going to be a sorry work because I already noticed that a huge lot of packages in the Ruby land fail their tests, and that’s not only with Ruby 1.9 or JRuby!
Another thing that is in a definitely bad shape in Gentoo is the scientific software, and the libraries. I’m not sure why is that but it seems like most of the people writing scientific software have no clue about build systems, portability, good programming practises and stuff like that. Probably, it’s tied to the fact that people writing scientific software are mainly scientists who have some vague idea about programming (you definitely will find it pointless to seriously use software written by programmers that have some vague idea about science). The result is that not only the ebuilds are sometimes way overcomplicated for the task they have to take care of, but they often breach QA, and end up failing badly as soon as something changes in their dependencies.
This alone wouldn’t be the problem if not that half the sci team, and similarly half the cluster team that seems to have been supporting them, disappeared with time, and now the ebuilds are mostly unmaintained. Thankfully, we’ve got people like jlec who’re still updating the ebuilds in the overlay, but this is the catch: either you keep the stuff in the overlay entirely or you’ve got to fix it in the main tree as well. We’re going to need some hands porting stuff over the main tree from the sci overlay.
And a similar problem happens with the LISP overlay: packages that are in portage, and used by other packages as well, end up failing with time, and the solution you find around is “just use the overlay”, which is no solution at all. Again, fortunately, Ulrich is moving some (requested) ebuilds from the overlay to the main tree as an user indicates, but it’s still a sorry state, and a dependency over overlays that we’ve artificially increased and it’s showing its limitations right now, to me at least.
And finally, another problem comes up when you look at the external kernel modules, which as the kernel team expressed many times are “simply evil”. While some tend to be at least vaguely maintained (think about iscsitarget that I’ve ported to 2.6.32 myself, but which I basically just stopped maintaining — I moved to sys-block/tgt that uses the SCSI target module that is already present in the Linux kernel, this way I have no more external modules in my system and I don’t need to rebuild packages at every update, or fix the build if it breaks), a lot are not.
We’ve still got a few packages that are designed to work only on Kernel 2.4 (since we’re going to prune old glibc versions, shouldn’t we start pruning 2.4 kernel support as well? it has been so long that I doubt anybody is still interested in it even in the most conservative environments), and there are quite a few modules that only work with pretty old kernels, like 2.6.24 (current udev also does not support them). The problem with those is that often times they require specific hardware; lacking that there is no way to ensure they work. And some of the maintainers of those are going missing over time.
So these are some of the directions we should try to work on more heavily. Hopefully somebody else will also join me since I cannot really do much more than I’m doing already at this point.
Shouldn’t this be on gentoo-dev?
Well, I have a very small experience at creating ebuilds. In a distant past, I tried to help maintaining Gentoo by taking care of some ebuilds, but then I was told at freenode that I would need to start working at the Sunrise overlay first.I was hoping to get my scientific packages to the portage tree too, which would make Gentoo the default distro for my kind of work (simulated soccer).What I’m trying to say is that Gentoo could benefit from being more receptive to newbie developers, who might, in a near future, be taking a lot of work and helping Gentoo to deploy the best QA you will get from a distro.
One thing that is also lacking is updated xen kernels.I am glad for linode supporting Gentoo, but the age of the kernel starts to show:Linux chuzzle 2.6.18.8-linode19 #1 SMP Mon Aug 17 22:19:18 UTC 2009 i686 Intel(R) Xeon(R) CPU L5520 @ 2.27GHz GenuineIntel GNU/LinuxI’m not complaining, just making a mention.Keep up the excellent work Diego!
wrt jlec: Kick the recruiters to get his bug done already. ;)@Edgeman: umm, you do realize that using a *linode* kernel has NOTHING to do with Gentoo right? They (not Gentoo) are providing the kernel for you. Me? I use 2.6.32 kernel on my linode 😉 http://www.linode.com/kernels/
@ Jeremy:Oh! I didn’t know you could do that…I was just going by this:chuzzle ~ # eix xen-sources* sys-kernel/xen-sources Available versions: (2.6.18-r11) ~2.6.18-r11!b!s (2.6.18-r12) ~2.6.18-r12!b!s (2.6.20-r7) [M]~2.6.20-r7!b!s (2.6.21) [M]~2.6.21!b!s {build symlink} Homepage: http://xen.org/ Description: Full sources for a dom0/domU Linux kernel to run under Xenand with what Linode supplied with the Gentoo template…
In a perfect world a few established developers would have time to monitor new ebuild maintainers. That way new people could work on the main tree quickly but experienced developers check their ebuilds carfefully to find errors.In reality, developers have way too much work already, entry for new is hard as badly written stuff might cause lots of extra work down the road.
A few months ago, when I had the feeling that the open number of package requests, bug reports etc on bugzilla was overwhelming, I contacted recruiters. The reply was basically “You can also help Gentoo when you are NOT a dev.” (Meaning, go away and do something on your own. We’re busy.)As I learnt in the meantime on IRC, the main obstacle in recruiting new developers is the lack of developers putting some effort into recruiting. So…
In my experience, getting ebuilds in science overlay is not hard, problem is their review and forwarding to main tree. More bugs are fixed in overlay, because, there are more people working on it (as it should be).
I think that out of there (or here… including myself after 5 years of gentoo abuse) there are a lot of “gentoo-power-users” used to reporting bugs, sends patches, manage a local overlay etc… They have abilities but (like almost everyone in this world) they don’t have time to take an overview of gentoo problems. Developers probably has such view of the areas where more help it’s needed, and this post is an example of that perspective.IMHO we need something to fill the gap… a way/place where developers can give instructions of tasks to be done that a power-user can do in his spare time.For example something in some way trivial like “Assure that every game ebuild generate a .desktop file” or “Check DOCS variable in those ebuilds” …. i mean, all the things that can help to save precious time to developers
“IMHO we need something to fill the gap… a way/place where developers can give instructions of tasks to be done that a power-user can do in his spare time.”IIRC this was supposed to be alleved with the useage of ‘herds’ Progress or not? What could be done to streamline this?
if someone finish to review my quizzes I can start to update and fix all the scientific ebuilds
“I’m not sure why is that but it seems like most of the people writing scientific software have no clue about build systems, portability, good programming practises and stuff like that.”Although I am a students of physics (some sort of scientist 😉 ) I can utterly confirm that! Currently I am working on the sage ebuild which is in my opinion the best example for your statement. It includes tons of other small projects, which are slightly modified and sometimes without documenting that. And at the end of compiling Sage you get a very long list with a variety of QA warnings. But even worse, the projects that are shipped with Sage are built with custom makefiles that will bring tears in ones eyes – some of these projects even ship their own version of other projects, for example an assembler (why not ?!) …
@user99sorry… i miss something in your post… can u explain better? (u mean ‘alleged’?)
@Fabio- alleviated or given some relief