July 4th, 2007
Lots of news around lately. aKademy is winding up; haven’t seen much visible posting about the Flash we handed out, which is a shame, but Helio, our man on the spot, tells me that inside the conference there were a lot of people coming up to him to talk about it and ask questions (like “How do I get KDE 4 on this thing?” :>), so that’s good. Hopefully people will be writing about it when they get home.
There’s been a full and frank exchange of views (;)) regarding the new Bugzilla on the Cooker mailing list. Things have got a bit confused: everyone more or less agrees that upgrading to 3.0 and dropping as many patches as possible is a Good Thing, but the discussion has now got tangled up in the question of the maintainer database (which is currently kinda intrinsically tied into Bugzilla) and the question of whether we should continue to list every package in the distribution as a component in Mandriva. Vincent proposed that we go with a small list of groups for components, instead of packages, which would simplify the list drastically and make a lot of important operations a lot faster (as downloading a list of some 9,000 components every time you file a new bug or do an advanced search is very slow). It would also avoid the need for the maintainer DB, more or less. Some people have objected to this on the grounds that it doesn’t really tie into our way of working; we don’t *have* maintainer groups for most packages in the distro.
I initially liked the idea, but I’m reluctantly coming around to thinking it’s probably impractical, at least at present. We can’t really cover the whole range of packages in Mandriva by splitting them into, say, 20 groups. This doesn’t map to how packages are actually maintained at all. So a ‘hybrid’ proposal was made, which would result in a larger number of smaller groups. I don’t like this either, though, because a 100-entry long component list is too long for reporters: you don’t want to go to Bugzilla and have to look through a list of 100 components to find the right one for your bug, that’s a horrible experience. So right now I feel like we’re kinda stuck with the packages-as-components situation, and the consequent slowness and need for a maintainer database. We could only really change if we created groups of packagers *first*, and proved that we could use that development style. We can’t change Bugzilla first and then try and kinda rejig our development process to fit our bug tracker, that’s not the right way around at all.
Couple of good pieces of news from the press team: firstly, the French Ministry of Agriculture and Fisheries is going with Corporate Server, secondly, an interesting press release on NEPOMUK, the ‘semantic desktop’ (think metadata) we’re playing a leading role in developing, and which is being integrated into KDE 4. Digg and Digg
I got embroiled in a bit of a brouhaha with various PCLinuxOS folks in the Distrowatch Weekly comments regarding the extent to which PCLOS is based on Mandriva – all in good fun and resolved amicably in the end. See also the discussion thread in the PCLOS forums (which gets a lot less heated towards the end, keep reading )
Tech stuff: I finished my work on EDE and uploaded it to 2007 Spring /backports along with Cooker. If you’re looking for an old-school, Win98-looking, fast yet slightly creaky desktop, give it a shot
After the wvstreams maintainer mentioned that he wants to release a new version of wvstreams but needed people to check whether wvdial still worked with it, I updated Cooker’s packages to his test versions and Michael Scherer was kind enough to test it out. The result was positive, so wvstreams 4.4 should be coming out in a few weeks if no-one else hits problems.
Otherwise, I’ve just been slowly continuing my trek through the old packages in Cooker – I’m working on 2007.0 stuff in /main now. I think my goal for 2008 is to make sure everything in /main has a 2008.0 tag, or as close as is practically possible. /contrib might have to wait for 2008.1, I’m afraid. Unless someone wants to help!