Because of the very annoying new Mozilla release politics (which look like a pissing contest with the similar annoying Google Chrome/Chromium release schedule), Ubuntu kicked out Mozilla XULRunner with its recent release of 11.10 Oneiric. And with XULRunner, Ubuntu also kicked out Conkeror and all other XULRunner reverse dependencies, too. Meh. Sparked by this thread on the Conkeror mailing list, I extended the Debian package s /usr/bin/conkeror wrapper script so that it looks for firefox in the search path, too, if no xulrunner* is found, and added an alternative dependency on firefox versions greater or equal to 3.5, too. From now on, if the wrapper script finds no xulrunner but firefox in the search path, it calls firefox -app instead of xulrunner-$VERSION to start Conkeror. With the expection of the about:-page showing the orange-blue Firefox logo and claiming that this is Firefox $CONKEROR_VERSION , it works as expected on my Toshiba AC100 netbook running the armel port of Ubuntu 11.10. From version 1.0~~pre+git1110272207-~nightly1 on, the Conkeror Nightly Built Debian Packages will be installable on Ubuntu 11.10 Oneiric again without the need to install or keep XULRunner version from Ubuntu 11.04 Natty. For those who don t want to use the nightly builds, I created a (currently still empty) specific PPA for Conkeror where I ll probably upload all the conkeror packages I upload to Debian Unstable.

Wishing the entire Debian community worldwide a happy and prosperous Gujarati New Year (Vikram Samvat 2068 called Shobhan.) The picture above, is one that's been making the rounds of the Indian blogosphere. It purports to be a NASA satellite image of India on Diwali (which was last night.) Actually it is a composite of several night shots taken over a period of a few years. Also the red dots are people who have been injured by fireworks and the green dots those immobilized by the ingestion of too much baraphi and halwa. But I could be wrong about that. I've had some terrific news these past few days but alas I'm not at liberty to divulge it just yet...

The RISE co-op is the sole shareholder in the Social Enterprise Mark CIC and its members have been called to an Extraordinary General Meeting during the lunch break of next Tuesday s Knowing and Growing conference at UWE Bristol. The RISE board has proposed Four Special Resolutions that would dissolve the co-op and transfer all assets as windfalls to the SEM CIC and a trust, ignoring RISE Ltd s Memorandum of Association. software.coop is calling on other RISE members to attend the EGM and oppose this demutualisation attempt. Update: dissolved but not demutualised (see below) RISE is constituted as a common ownership co-op and its Memorandum of Association contains a clause that directs the assets to be transferred to another common ownership social enterprise organisation if the co-operative is dissolved. However, unlike the CIC asset lock, there is no independent regulator enforcing it and, unlike in many co-ops, there has been no requirement for new members to pledge to obey the RISE common ownership clause at an individual level and there has been no member education about common ownership in the last three years. This demutualisation is the wrong solution for RISE because:

• it has recieved much public money and money from members on the understanding that it would be kept in common ownership;
• there are common ownership social enterprises that could really benefit from the legacy assets at this time of budget cuts, but if those assets go to a CIC, they are lost from common ownership;
• the EGM is the day after the global launch of the United Nations International Year of Co-operatives, which is about promoting mutualism around the world and the RISE co-operative should support this;
• many RISE members are mutuals, including the world s largest consumer co-operative and demutualisation would be embarassing to them;
• demutualisation should be discussed seriously, through a proper democratic process before the regular Annual General Meeting, not sprung from the board to members in a short meeting during the lunch break of another event;
• the proposal has not been published on RISE s website or email newsletter;
• appointing the former directors of a dissolved co-op as trustees without member oversight seems unlikely to secure the assets in the long term.

software.coop will vote against the demutualisation, in favour of social enterprise, and calls on other RISE members to show solidarity with the co-operative and common ownership social enterprise movements. Update 2 November: rise has announced its dissolution but they ve got to give further consideration to where the assets go because the demutualisation resolutions were defeated. I fear that they ll still try some way to bail out the Social Enterprise Mark despite the rejection, but I hope they ll do the right thing and give the assets to good common ownership social enterprise like the RISE Memorandum of Association requires.

After finalizing DOF Calc 0.1.0 yesterday, I've decided to push new version of GePeS as well. The update utilizes new Meego loader, so application should start much faster, add azimuth calculation for sun (set, rise and current) as well as compass is utilized for showing this azimuth. You can check all new features on screenshots page. New version is currently available in git and tarballs, binary version will be in Nokia store as soon it passes QA tests there.

Filed under: English Meego 0 comments Flattr this!

On a recent visit to my local e-waste disposal place I noticed an open PC on the top of the pile with a pair of DIMMs that were begging to be removed. I also noticed three PCI Ethernet cards that were stacked in a manner that made them convenient to grab possibly some nice person deliberately placed them so someone like me could take them. The DIMMs turned out to be 3G of DDR2-800 RAM and were regarded as good by Memtest86+ a nice upgrade for one of my test systems that previously only had 1G of RAM. If you have old hardware to dispose of then please try to take the RAM to your local computer users group meeting. In any such gathering there s always someone who wants old RAM, anything better than PC-133 will find good home unless it s very small (128M sticks of DDR-266 and 256M sticks of anything faster probably won t get any interest). RAM is small and light so you can carry it in your pocket without inconvenience. Ethernet cards of all vintages are in demand due to people reusing old desktop systems as routers and PCIe video cards are in great demand, PCI and PCIe cards are small enough that it s usually not a great inconvenience to transport them. Hard drives larger than about 100G are in demand as are ATX power supplies, these are really inconvenient to transport unless you travel by car. For computer systems, anything that can use DDR2-800 RAM will probably be of use to some member of a computer users group, if you offer it on the mailing list then you can expect that someone will want to collect it from you at your home or a meeting. There are organisations such as Computerbank that take donations of old hardware and make systems for disadvantaged people [1], it s worth considering them if you have hardware to dispose of. But for me the hardware I use every day is quite close to the minimum specs for donations that Computerbank will accept so there s no possibility of me discarding systems that are useful to them. I ve created a page listing hardware that I need, if anyone in my area has such hardware that they don t need then please let me know [2].

• [1] http://www.computerbank.org.au/recycle
• [2] http://etbe.coker.com.au/hardware-i-need/

Well, when I got an invite to try G+, I decided to make my first foray into social networking sites since friendster. It was mildly interesting while it lasted, however it seems that it is over for me now. I tried to use the name "Mike (stew) O'Connor" as I do on my gpg key. This caused my accounted to get flagged as violating their "real names" policy. I can't help but to feel a little offended that they think they know what my name is better than I do. I have a bit of a unique situation with my name. Pretty much NOBODY calls me "Mike" or "Michael" save a few people from my childhood. Its been this way for more than half of my life. My wife only ever has called me "stew". My two year old knows my name is "stew" but doesn't know my name is also "Mike". If I meet somebody new, I always introduce myself as "stew". All my clients call me stew... The instructions on google plus tell you "To help fight spam and prevent fake profiles, use the name your friends, family or co-workers usually call you.", So when my account was initially flagged. I tried changing my name to "Stew O'Connor". My account was "pending review" and I was still able to post and reply and the like. After review, my account was suspended, some of my privacy settings were changed, and I cannot change them back. Out of the 60 or so people that added me on G+, only one of them should ever be referring to me as "Mike". When someone calls me Mike that isn't one of the handful of people that "should" be calling me "Mike", my brain immediately puts them in the "oh, you don't know me very well" category. Oh well, Google, amazingly, you don't know me very well. After explaining to someone "oh, no you really should call me stew like everyone else", you say "No, I'd rather just not talk to you", now you are just being a jerk. Now I guess I have a retort to people that use the phrase which I find so annoying: "GIYF". Update: I appealed to change my name to Stew O'Connor which was denied, then appealed to change my name to Mike O'Connor which was also denied. I guess I was supposed to use "Michael" or something? Being denied "Mike", I deleted my suspeneded G+ account, feeling extra flouncy, chnaged by default search engine to duckduckgo.com.

You might have read my recent post about an open redirect on WEB.DE's homepage. Now, as it turns out, the spread of this particular bug is far wider, than I first thought. After posting the previous story, I was surprised, how long it's taking to fix the bug. Then I remembered, that the domain for the redirect wasn't web.de but ui-portal.de. Now, knowing that WEB.DE is owned by United Internet doesn't make it that suspicious, but I was intrigued enough to check what the DNS said about the domain. And, as it turns out, the domain points to an IP owned by comScore/Nedstat:

$ dig @85.214.73.63 wa.ui-portal.de
; <<>> DiG 9.7.3 <<>> @85.214.73.63 wa.ui-portal.de
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51273
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 3
;; QUESTION SECTION:
;wa.ui-portal.de.               IN      A
;; ANSWER SECTION:
wa.ui-portal.de.        10      IN      CNAME   wa-ui-portal-de.sitestat.com.
wa-ui-portal-de.sitestat.com. 30 IN     A       77.72.113.50
;; AUTHORITY SECTION:
wa-ui-portal-de.sitestat.com. 83 IN     NS      glns03.sitestat.com.
wa-ui-portal-de.sitestat.com. 83 IN     NS      glns02.sitestat.com.
wa-ui-portal-de.sitestat.com. 83 IN     NS      glns01.sitestat.com.
;; ADDITIONAL SECTION:
glns01.sitestat.com.    24      IN      A       77.72.113.10
glns02.sitestat.com.    24      IN      A       77.72.115.10
glns03.sitestat.com.    24      IN      A       87.249.105.10
;; Query time: 63 msec
;; SERVER: 85.214.73.63#53(85.214.73.63)
;; WHEN: Wed Oct 26 14:27:54 2011
;; MSG SIZE  rcvd: 202

All that is missing now, to confirm everything, is a whois for 77.72.113.50, which shows Nedstat B.V. as the owner (Nedstat is a part of comScore since 2010). That was, when I realized, that there are probably a lot more sites offering such links, and as a search for inurl:ns_url=http shows (I'm not yet linking to a result page, but you can look it up yourself, of course), that assumption was correct. There are some big names like Siemens or the Bertelsmann Stiftung, using the click-tracking service by Nedstat, returned by the search. That is a problem, as links looking like they're pointing to a trustworthy site/domain have a high potential for being clicked. Most people won't notice the open redirect, especially not, if the attacker took some time to design a target page, that looks like the original (most likely for phishing) or let the redirect point directly at some installer for malicious software or both. I've informed Siemens and the Bertelsmann Stiftung too, but I can't inform every affected website operator, so I've informed comScore/Nedstat directly and hope, they'll fix the issue in a timely manner. And not less important: inform their customers immediately.

I've been doing some updates to DOF Calc in last days and today I decided it's time to push new it to public. The application has been switched to dark theme (which seems to be preferred one) and got working settings module. This means you can now configure list of cameras, lenses and apertures it offers, so that only choices you really use will be show. New version is currently available in git and tarballs, binary version will be in Nokia store as soon it passes QA tests there. Besides that, application got new homepage with screenshots (what is true for GePeS as well).

Filed under: English Meego 0 comments Flattr this!

Well, yesterday out of nothing my webmailer roundcube started to refuse to work. At least as I remember it. For some reasons reloading the Inbox just showed the "Loading..." message on the screen, but there was no list of mails anymore. Funny enough other folders do actually work as before. But anyway, doing an update did not help and improve anything. (I really don't know whether I updated before or after because of the first occurence of this issue.) There's an entry in syslog when loading the Inbox folder:

Oct 26 07:24:59 muaddib suhosin[32432]: ALERT - Include filename ('http://www.gnu.org/s/hello/manual/automake/ ?.php') is an URL that is not allowed (attacker '127.0.0.1', file '/usr/share/roundcube/program/include/iniset.php', line 110

This lead to bug #1488086 in the Roundcube issue tracker which states:

This messages made me wonder why suhosin thinks there's an include going on. Line 111 of iniset.php shows: include_once("$filename.php"); It seems like roundcube wants to include what is displayed in the subject, which happens to be a url - and suhosin legitimately blocks this attempt. In short, I can send an email to a user on a suhosin protected mail server and make his inbox unavailable. Needless to say, the user cannot delete this email himself via RoundCube. In my case, I had to delete the email file on the server to make roundcube show the inbox again.

In Debian there's bug #619411 that is related to PATH setting in iniset.php, but I'm not sure if this is really related to #1488086 in the Roundcube issue tracker and my problem? However, disabling suhosin doesn't seem the right way to "solve" this issue and the trac issue tracker suggests a security related problem. Anyway, I filed this as bug #646675 in Debian, waiting for the bug number. But when someone else knows some quick fixes or something I can try, please speak up! :-) UPDATE: It seems as if some mail triggered this issue like reported in the Roundcube ticket. After filtering my mails with Iceweasel, I'm being able to read my Inbox now again.

Review: Scrum and XP from the Trenches, by Henrik Kniberg

Publisher:	InfoQ
Copyright:	2007
ISBN:	1-4303-2264-0
Format:	Trade paperback
Pages:	127

For those not already familiar with it, Scrum is a project management methodology that's most often seen in the agile software development community. It attempts to do for project management what agile techniques do for software development (and, other than test-driven development, I think is more useful than most of agile). I'm not going to explain it here in detail, but if you do software development or project management of software-style projects (including integration and computing infrastructure), it's worth your attention. It provides some nice techniques for dealing with some of the banes of technical projects, particularly constantly changing requirements and the difficulties of estimates. Scrum and XP from the Trenches is subtitled "How we do Scrum" and is exactly what it says on the tin. It is a fairly detailed description of how Crisp (an agile Java development company in Sweden) does Scrum (with a little discussion of Extreme Programming). It doesn't explain what Scrum is, although it does provide a few pointers to resources if you've never heard of it (but this isn't the sort of book you'd be buying if you'd never heard of it). It also doesn't try to convince you that Scrum is wonderful, which is a nice trap to avoid. It gets right down to business and packs quite a bit of relentlessly practical content into a small number of pages. I've been doing Scrum for about a year, across two large projects, both times not entirely following the full Scrum model. Both times, most of the team was learning Scrum during the project. I've gone to some Scrum training and read a bit, largely on-line, but I haven't made an exhaustive study of it. I think I'm exactly the ideal audience for this book, although my guess is that people who have been doing Scrum for longer will also get something out of it. This is not an introduction; I don't think one is likely to get much benefit out of it without a couple of Scrum projects under one's belt so that one has a feel for the problems and failure modes. As Kniberg accurately points out, Scrum is a framework, not a precise rule set, and it can't be applied blindly in one situation using analysis from another. For that audience, though, this book is great. Kniberg has used Scrum in a variety of different situations and tried multiple solutions to many of its problems, so he can provide guidance not only on his preferred solutions but on the other solutions he's tried and why they don't work. I started taking extensive notes just a few pages in; it was exactly the book I needed to read for the full-project retrospective on how Scrum worked for a just-concluded work project, and for planning what changes we'll want to make for the next project. He goes through every step of the Scrum cycle and offers advice on each step, particularly for the sprint planning (which was extremely helpful). He then walks through release planning and advance estimation (one of the best parts of the book; I've seen the concept of a focus factor before, but this is one of the best and clearest explanations I've seen), talks about XP (Extreme Programming) techniques and testing, and then discusses how to coordinate multiple Scrum teams in a larger organization. The chapter on testing was the reason why I bought the book; the rest of the book lives up to it. As mentioned, my Scrum exposure is not broad, so Kniberg may just be following different orthodoxies. That said, he broke with the ones I was previously familiar with in some useful places. One is to attach a time unit to story points, something that I was told was close to anethema, but as presented here looks very useful. Another, not so much a break but an idea that I'd not encountered elsewhere, is downtime between sprints, an brilliant solution to a problem that I'd not even fully articulated but which had been plaguing our Scrum process. He also has some suggestions about communication that, while fairly obvious and common-sense stuff, still were things that hadn't occurred to me and that we should adopt. I paid for a hard-copy version of this book from Lulu because I like things like this on paper and am happy to support the author financially, but you can download a PDF file and read it for free from InfoQ and see whether it works as well for you as it did for me. If you're ramping up on Scrum, seeing some problems, and looking for good ideas on how to fix them, I highly recommend it. I'd love to read two or three more case studies like this to get some more perspectives on how to make Scrum work. The paper book will likely be making a circuit around our office to serve as fodder for our upcoming Scrum projects. Rating: 8 out of 10

There are six servers. They're meant to be used for the same purpose, and are mostly the same too, but not quite entirely. This being the case, mostly because of how they were maintained in the past: with cssh mostly, but it's inevitable that eventually there will be differences. So we're in the process of migrating them to puppet now. One of the things I need to do while doing that, however, is figure out what the differences are, and get rid of them where applicable. Differences such as, say, in the installed packages. Some of these servers have extra things installed, for a reason that isn't clear anymore, that others don't. So how does one figure out what the difference is? If this were two servers, I'd create a list of installed packages and use 'diff' on them. If there were three, I'd use 'diff3' instead. But if there are 6? Turns out that isn't too hard. First, of course, you need a list of packages installed on each individual host. Both rpm and dpkg can do this with a simple command line invocation. Assuming that's done, and the output is stored in files called installed-host1 through installed-host6, the procedure is:

$ comm -12 installed-host1 installed-host2 > installed-common
$ for i in $(seq 3 6)
> do
>   comm -12 installed-common installed-host$i > installed-tmp
>   mv installed-tmp installed-common
> done

And there, you now have a file "installed-common" containing everything which is installed everywhere. If you use "comm" or "diff" to compare that file against the installed-hostX files, you can easily see what the difference is. Granted, that doesn't give you the overview in just one file, but usually that's not really necessary. The 'installed-common' file contains the largest common denominator, which really is everything you need.

Reading Sylvestre Ledru's announcement, that sun-java6 was removed from the archives, I'd like to point out, that the recommended immediate purge of any binary packages built by sun-java6 should be postponed until you did have time to check, that important applications are working for you with the OpenJDK implementation. I need to retain sun-java6-plugin until upstream bug #588 for icedtea-plugin is fixed. If you have equal requirements (using ELSTER is required by tax law for me), make sure everything works with OpenJDK/IcedTea, otherwise you need to fetch the latest shipped version from snapshot.debian.org or install something directly from Oracle. Now, as security issues were mentioned in Sylvestre's post, I'm NOT recommending to have sun-java6-plugin running in your browser on default. Just switch the Java plugins before you really need it. For Iceweasel you can (de-)activate plugins in the add-on manager's plugin tab. Apart from that I'd recommend to not surf with any scripting or plugins active at all, NoScript! is a great way to do this conveniently.

As said in one of my previous blog post, we, Debian, were going to remove sun-java6 packages from the archive once critical security issues would come. It was supposed to happen sooner and later and here we are. The version 29 (see the #645881 Debian bug) of the Oracle proprietary JVM has been released. It fixes some critical issues but, because of the DLJ removal, Debian is no longer able to distribute it. Unfortunately, we have no other choice than asking for a removal from the archive and promote the use of the openjdk 6 & 7.
The conclusion is:
apt-get --purge remove sun-java6-jre && apt-get install openjdk-7-jre

It s been busy at our co-op but I m never too busy to support calls for the freedom to install debian (or any other Free and Open Source Software Operating System) so I ve signed the FSF-led public statement on so-called Secure Boot .

This could be a feature deserving of the name, as long as the user is able to authorize the programs she wants to use, so she can run free software written and modified by herself or people she trusts. However, we are concerned that Microsoft and hardware manufacturers will implement these boot restrictions in a way that will prevent users from booting anything other than Windows.

So please, read the full thing and consider signing it yourself. If you want to watch for further news on this topic, Matthew Garrett s Journal seems to be the bomb. Right, well, it s another busy week this week, so it might be the weekend before I find time to blog again, but posts will be a bit more frequent next week: watch this space!

I realise it has been nearly two months since I last posted anything here. The good news is I'm still alive! Mostly the past couple of months has been full of cute victims to take pictures of, which has helped me setup a simplified portfolio site;

• Edinburgh Portraits

I still continue to prefer images of people and I was recently pleased with the delivery of my first "photobook". Over the past couple of years I've slowly decorated my flat with prints (4"x6" - A2) of my pictures, but seeing the pictures in a nicely bound book makes them feel so much more real. I've also been doing a little more software development, mostly relating to the archiving of images and the workflow of taking RAW images, converting them, and finally uploading via rsync. I suspect the tools I've put together are Steve-specific, but I did have some fun with duplicate image detection and eilimination - something I've written about in the past. ObQuote: "Better to write for yourself and have no public than to write for the public and have no self" - Cyril Connolly.

I was in Brazil last week and had the pleasure of participating in a teach-in at Occupy S o Paulo, a vibrant camp set up last week in the heart of the old down town. There are now under threat, please see below for details and spread the word. *** On October 15, a group of nearly 300 activists began an occupation of S o Paulo in the Valley of Anhagabau, one of the sites of the first rallies for direct elections during the end of the Brazilian military dictatorship in the 1980s. After a week of peaceful encampment, educational and cultural programs, and creating a sustainable community for not just themselves but many homeless people in downtown S o Paulo, the Occupy S o Paulo movement is coming under increased police threat. Today, Monday October 24, the governor of the state of S o Paulo, Geraldo Alckmin is holding two special events. First, he is hosting Florida Governor Rick Scott (R). Second, Alckmin has decided to hold a parade of 3000 military police right next to the encampment (see photo above). After a week of police harrassment and a pending court case for them to hold the right to pitch their tents, the Occupy S o Paulo movement sees this as an escalation of the harassment they have already faced by city police. Further, the presence of 3000 military police next to 300 occupiers is clearly meant to intimidate both occupiers and members of the public who have been coming up to the encampment and learning about the movement. Please take the time to call or email the governor and the secretary of public security of the state of S o Paulo to condemn this action. You can also send messages of solidarity to the S o Paulo occupation at occupysampaenglish@googlegroups.com. To contact Governor Geraldo Alckmin s office of citizen and organizational relations: Fill out a comment form at: http://www.saopaulo.sp.gov.br/en/fale/fale.php
Phone: 55-11-2193-8463 To contact the Secretary of Public Security, Ant nio Ferreiro Pinto:
Email: seguranca@sp.gov.br
Phone: 55-11-3291-8500

As is natural for an LTS cycle, lots of people are thinking and talking about work focused on quality rather than features. With Canonical extending LTS support to five years on the desktop for 12.04, much of this is quite rightly focused on the desktop. I'm really not a desktop hacker in any way, shape, or form, though. I spent my first few years in Ubuntu working mainly on the installer - I still do, although I do some other things now too - and I used to say only half-jokingly that my job was done once X started. Of course there are plenty of bugs I can fix, but I wanted to see if I could do something with a bit more structure, so I got to thinking about projects we could work on at the foundations level that would make a big difference. Image build pipeline One difficulty we have is that quite a few of our bugs - especially installer bugs, although this goes for some other things too - are only really caught when people are doing coordinated image testing just before a milestone release. Now, it takes a while to do all the builds and then it takes a while to test them. The excellent work of the QA team has meant that testing is much quicker now than it used to be, and a certain amount of smoke-testing is automated (particularly for server images). On the other hand, the build phase has only got longer as we've added more flavours and architectures, particularly as some parts of the process are still serialised per architecture or subarchitecture so ARM builds in particular take a very long time indeed. Exact timings are a bit difficult to get for various reasons, but I think the minimum time between a developer uploading a fix and us having a full set of candidate images on all architectures including that fix is currently somewhere north of eight hours, and that's with people cutting corners and pulling strings which is a suboptimal thing to have to do around release time. This obviously makes us reluctant to respin for anything short of showstopper bugs. If we could get things down to something closer to two hours, respins would be a much less horrible proposition and so we might be able to fix a few bugs that are serious but not showstoppers, not to mention that the release team would feel less burned out. We discussed this problem at the release sprint, and came up with a laundry list of improvements; I've scheduled this for discussion at UDS in case we can think of any more. Please come along if you're interested! One thing in particular that I'm working on is refactoring Germinate, a tool which dates right back to our first meeting before Ubuntu was even called Ubuntu and whose job is to expand dependencies starting from our lists of "seed" packages; we use this, among other things, to generate Task fields in the archive and to decide which packages to copy into our images. This was acceptably quick in 2004, but now that we run it forty times (eight flavours multiplied by five architectures) at the end of every publisher run it's actually become rather a serious performance problem: cron.germinate takes about ten minutes, which is over a third of the typical publisher runtime. It parses Packages files eight times as often as it needs to, Sources files forty times as often as it needs to, and recalculates the dependency tree of the base system five times as often as it needs to. I am confident that we can significantly reduce the runtime here, and I think there's some hope that we might be able to move the publisher back to a 30-minute cycle, which would increase the velocity of Ubuntu development in general. Maintaining the development release Our release cycle always starts with syncing and merging packages from Debian unstable (or testing in the case of LTS cycles). The vast majority of packages in Ubuntu arrive this way, and generally speaking if we didn't do this we would fall behind in ways that would be difficult to recover from later. However, this does mean that we get a "big bang" of changes at the start of the cycle, and it takes a while for the archive to be usable again. Furthermore, even once we've taken care of this, we have a long-established rhythm where the first part of the cycle is mainly about feature development and the second part of the cycle is mainly about stabilisation. As a result, we've got used to the archive being fairly broken for the first few months, and we even tell people that they shouldn't expect things to work reliably until somewhere approaching beta. This makes some kind of sense from the inside. But how are you supposed to do feature development that relies on other things in the development release? In the first few years of Ubuntu, this question didn't matter very much. Nearly all the people doing serious feature development were themselves serious Ubuntu developers; they were capable of fixing problems in the development release as they went along, and while it got in their way a little bit it wasn't all that big a deal. Now, though, we have people focusing on things like Unity development, and we shouldn't assume that just because somebody is (say) an OpenGL expert or a window management expert that they should be able to recover from arbitrary failures in development release upgrades. One of the best things we could do to help the 12.04 desktop be more stable is to have the entire system be less unstable as we go along, so that developers further up the stack don't have to be distracted by things wobbling underneath them. Plus, it's just good software engineering to keep the basics working as you go along: it should always build, it should always install, it should always upgrade. Ubuntu is too big to do something like having everyone stop any time the build breaks, the way you might do in a smaller project, but we shouldn't let things slide for months either. I've been talking to Rick Spencer and the other Ubuntu engineering leads at Canonical about this. Canonical has a system of "rotations", where you can go off to another team for a while if you're in need of a change or want to branch out a bit; so I proposed that we allow our engineers to spend a month or two at a time on what I'm calling the +1 Maintenance Team, whose job is simply to keep the development release buildable, installable, and upgradeable at all times. Rick has been very receptive to this, and we're going to be running this as a trial throughout the 12.04 cycle, with probably about three people at a time. As well as being professional archive gardeners, these people will also work on developing infrastructure to help us keep better track of what we need to do. For instance, we could deploy better tools from Debian QA to help us track uninstallable packages, or we could enhance some of our many existing reports to have bug links and/or comment facilities, or we could spruce up the weather report; there are lots of things we could do to make our own lives easier. By 12.04, I would like, in no particular order:

• Precise to have been more or less continuously usable from Alpha 1 onward for people with reasonable general technical ability
• Canonical engineering teams outside Ubuntu (DX, Ubuntu One, Launchpad, etc.) to be comfortable with running the development release on at least one system from Alpha 2 onward
• Installability problems in daily image builds to be dealt with within one working day, or preferably before they even make it to daily builds
• The archive to be close to consistent as we start milestone preparation, rather than the release team having to scramble to make it so
• A very significant reduction in our long-term backlog of automatically-detected problems

Of course, this overlaps to a certain extent with the kinds of things that the MOTU team have been doing for years, not to mention with what all developers should be doing to keep their own houses in reasonable order, and I'd like us to work together on this; we're trying to provide some extra hands here to make Ubuntu better for everyone, not take over! I would love this to be an opportunity to re-energise MOTU and bring some new people on board. I've registered a couple of blueprints (priorities, infrastructure) for discussion at UDS. These are deliberately open-ended skeleton sessions, and I'll try to make sure they're scheduled fairly early in the week, so that we have time for break-out sessions later on. If you're interested, please come along and give your feedback!

Google mentors summit 2011 is over. It is hard to believe but we had way more discussions about open science, or open data, open source, and open access than on all machine learning open source software workshops combined. Well, and the number of participants oft the science sessions was unexpectedly high too. One of the interesting suggestions was the science code manifesto suggesting among other things that all code written specifically for a paper must be available to the reviewers and readers of the paper. I think that this can nicely be extended to data too and really should receive wide support! Besides such high goals the summit was a good occasion to get in touch with core developers of git, opencv, llvm/clang, orange, octave, python... and discuss about concrete collaborations, issues and bugs that the shogun toolbox is triggering. So yes I already fixed some and more to come. Thanks google for sponsoring this - it's been a very nice event.

My generous employer has kindly offered to host the first Bug Squashing Party of the now commencing Wheezy Release BSP Marathon. Yay! We'll meet during the first weekend in December (Friday 2nd to Sunday 4th) in Hildesheim, Germany. There's a wiki page listing all important information. Please also use this page to sign up if you want to join us.

Today I attended the Stop HRL demonstration [1]. The government plans to spend $100,000,000 of federal money and $50,000,000 of Victorian state money to build a new coal power station. The state government has imposed some unreasonable restrictions on renewable energy which includes allowing a single person who objects within 2Km of a wind turbine to block the project while also not allowing anyone to object to coal power plants or fracking (both of which have proven health implications). Today VCAT had a hearing about this issue, HRL wants to double the size of the proposed coal power plant while Environment Victoria, Doctors for the Environment Australia, local climate action group Locals Into Victoria s Environment Martin Shield from Climate Action Moreland are opposing the plan. What the government should be doing is permitting (if not encouraging) renewable energy production, particularly wind power which will drive down energy prices by undercutting the energy auctions due to it s almost zero marginal cost. The government should not be spending tax payer money on new coal projects due to climate change and air pollution in addition to the fact that coal is simply more expensive in the long term. As usual it s disappointing that the National party which supposedly represents farmers is supporting the government in such things. The pollution caused by coal power and fracking ends up damaging farmland. The Liberal party doesn t have a majority on it s own in either house of the state government, so this proposed coal power plant could be stopped immediately if the National party supported renewable power, or even if they merely opposed giving $50,000,000 of state tax money to HRL. The demonstration went reasonably well, there was about 80 people there when I arrived and by the time it ended there were more than 150 people. I took the above picture at the start and it missed many people who were off to the right. I think that s a good result for a demonstration that had little publicity and was held in business hours with really bad weather. Update: On Sunday the 13th of November at 13:00-14:30 there is a Going Backwards Under Baillieu demonstration at Parliament House. This is to mark the negative affects that the Liberal state government has had on the environment of Victoria.

• [1] http://www.stophrl.org/