Long title, hopefully catchy enough so that both users and fellow developers can get to read this, since it’s half a rant, half an explanation on why the QA team can be quite anal when it comes to bugs that, for most developers, and especially for the maintainers of the packages involved, might look minor or not causing problems to the general population of users.
Today’s problem for instance was with packages that, for non-live (thus, snapshot or release) versions used the SCM eclasses, fetching directly from CVS, Subversion, GIT, Mercurial and so on. QA already have stated that the ebuilds using SCM eclasses should be masked (it’s in the devmanual if you wish to look at it), and that by extension should tell that using them for relesed code is bad. Among the various reasons for not using SCM eclasses for proper versions of the software, no matter whether upstream has or hasn’t made any serious release, there are safety involvements (you sidestep the Manifest in portage) and problems with proxy (not all SCMs use HTTP for fetching), but what creates quite a bit of a problem to me with the tinderbox: those ebuilds don’t abide the fetch command! When I run the tinderbox, I launch in parallel both a build sequence and a fetch sequence (I cannot use the parallel fetch feature because I launch each package one by one); when the packages using SCM hit, they spend time not building, which is bad for the tinderbox. And it gets even worse when you add stuff like the old, removed rubinius that spent time timing out because the server went away.
But the same class of problems involve using too big files in the tree: when you add a 100K patch for a package that just a few users are going to merge, you’re wasting bandwidth and disk space for a huge amount of people who just don’t care. That’s why we stress the need for making filesdir as lightweight as possible without messing with the development process, of course. Again, this is just another little task for the developer: package the patches and send them on the mirrors, then add them to the ebuild so that they are only downloaded by those who do need them.
And again it’s the same problem with packages ignoring compilers, compiler flags, linker flags, or prestripping when they shouldn’t. These are a problem because one of the selling points of Gentoo is the customisability of it all, at all different levels. So while they might be seen as minor points, these are all the little details that the QA team has to answer for. And it goes on and beyond this, making sure software builds, that it builds in parallel if it’s possible, that it doesn’t fail with new version of dependencies, that it builds with the correct kernel.
So please help us helping everybody, and don’t just ignore our requests, or start a pissing contest on why your package should be special, and not abide to the common rules and directions of the rest of Gentoo. Sorry, but unless it is really special, and that’s pretty rare, your software will have one way or another to abide to those rules, and if I have to piss you off by forcing the decision as QA, then I will. I hope I won’t have to, though.