As I'm wrapping up my 1 year contract with SLX Debian Labs to work on debian-edu, I felt I should try to summarise what I've done during this year on the job, how well I've managed to meet the goals laid out in my contract and task list, and what areas I've fallen short on, as well as imparting any advice I can for SLX or others based on my experiences during this year. I'll start by taking goals from my task list (work-joey-hess.txt in CVS), and analysing how well they were accomplished, starting with the overall goal of my employment: | We want Sarge to release as soon as possible, including all the | packages Debian Edu want and need to be able to release the next | major release of Debian Edu with packages only from Sarge. Part of the overall goal was to release Sarge ASAP. Unfortunatly, sarge is still not released, although I'm hopeful that it will release soon, but we never expected I could somehow make sarge release on its own. I do think that I've been able to contribute to getting the sarge release out by various activities including: - Making several d-i releases in the past year, each of which became progressivly closer to a real Debian release. - Keeping d-i working at all times so it was never a release blocker for sarge in the past year, while still letting in enough improvements to keep the interest of the d-i team high. - In my capacity of release assistant, I've worked on RC bugs, worked on getting RC bug fixes into sarge in a timely fashion, and generally participated in the release team. - Launching the testing-security team and our tracking pages, which the Release Managers are on record as finding very useful in tracking which security holes need to be fixed in sarge. - Attending the Vancourver release team meeting, which I do hope will eventuallly result in fixing some of the issues that have delayed the sarge release, and which did in fact help speed up the reelase in some areas. Overall, I feel I've done as well at getting sarge released as can reasonably be expected of one person, but I'm still disappointed that it was not released last year. The other main part of the overall goal was to "release the next major release of Debian Edu with packages only from Sarge", and the task list goes on to explain that: | To be able to release Debian Edu with package only from Sarge, we need | to make sure | | - the packages in Sarge can be installed out of the box with the | configuration we want to use in Debian Edu The ideal way to achieve this goal would be to get all the debian-edu config changes available as debconf options or the like. This has been done for some things, but many configuration changes are still done as they were for skolelinux. To the extent that (more or less) all the config changes that we need are accomplished by the Debian edu install process, I consider I've partially met this goal, but it's also clear that I haven't fully met it, and more work in this area in the future would be useful. | - all the packages we want are included in Sarge A look at ~ftp/skolelinux/dists/sarge/local/binary-i386 on developer.skolelinux.no shows that this goal has not been completly met; we have 47 debs and 3 udebs that are different from what is in sarge. Compare that with skolelinux which has some 406 changed debs and 6 changed udebs and things have obviously improved; a large part of this improvement is due to not needing to backport many new upstream versions as had to be done for woody. Breaking this down further, all the changed udebs in debian-edu have slightly older versions in sarge; we put newer versions on developer only to more quickly test new developments. It's possible that sarge will release with older versions of our udebs, but this would only be a minor problem. Many of the debs (debian-edu-config, the education tasks, lessdisks) are similar to the udebs. I feel that I did a better job at pushing these kinds of changes into sarge for the first 6 months or so of my work and worse in the last 6 months. Partly because I began to releasize that if sarge did not really release in a given month, spending too much time on making sure things were closely in sync was a waste of time. There is still one significant set of debs that are in debian-edu but not in sarge: ltsp. This was not fixable, and I'm glad that we have lessdisks as an increasigly usable option now. I myself did little work on lessdisks though, and I do feel I should have done more in this area. The task list listed some more goals: | - Improving on debian-installer, both to make sure Sarge is released, | but also to make sure the automatic Debian Edu installation keeps | working while d-i is changing. I feel that I've fully accomplished this goal. | - Keeping an eye on the ~900 packages used by Debian Edu, making sure | the latest and greatest version is included in Sarge. The package | debian-edu contain the package list. I used this goal as a way to prioritise my work as a Debian release manager and my work on testing security. When chosing issues to work on, I tended to prioritise packages in debian-edu. | - Finding maintainers for the packages Debian Edu want to get into | Sarge, or maintain the packages ourselves (LTSP, locale | configurator, Cerebrum, kde menu editor, webmin modules, nagios | setup, java and flash browser plugins, etc). I didn't do very much toward this goal. I neither took over maintainership of any of these packages, nor did I actively try to find maintainers. My excuse is that other people seemed to become active in at least some of these (localisation-config, ltsp, cerebrum, etc) without my help, so I reallocated the time elsewhere. | - Start security patching of Debian Testing, to make sure Sarge is | easier to Release. This includes forming a team of people working | on this. This is one of the things I'm most satisfied with of the work I've done. Not only has the team been formed, but it seems to be fairly self sustaining, the release managers have found it useful, we have a better idea about just how many security holes there are in testing and how long it tends to get them fixed. The one mistake I made is putting off forming the team until last fall. I'm in debt to Petter for nudging me to begin work on it after too long a time of being scared to really get started. I don't feel this mistake had any net ill effects though, since we quickly caught up on security fixes. | - Supply patches for the existing packages in Debian to make sure | they are usable out of the box for Debian Edu. (the config is in | debian-edu-install and debian-edu-config). As discussed above, I didn't really find time to do this. One problem has certianly been that with the release of sarge apparently just around the corner for so long, there's resistance to making this kind of change before sarge is released, out of fear it will cause problems. This is definitly an area that will need more attention after sarge is released. | - Improve the upgrade path from the Debian/Woody based version of | Debian Edu to the Debian/Sarge based version. I didn't manage to work on this, though some others have done some work. It's still a big problem. The main problem I had on working on it is a lack of past experience administering (or even installing) skolelinux systems, which meant I lacked any practical experience that would be needed to deal with this. I now have the practical experience to deal with upgrades from sarge based debian-edu to whatever comes after it, but skolelinux is still not something I've gone back and learned enough to do any serious work on this. The task list concluded with some points that would be used to measure my success at acheiving the tasks: | - Weekly reports to the list about progress and status I've kept these coming, although several times the press of events has made me miss one and have to do a two-week report. I have to say that finding things to put in the weekly reports has been both a good way to keep focused on work that will help debian-edu, as well as very annoying at times. It's horrible when I spend a week working on some hard problem and end up with only "worked on some hard problem, not done yet" for the weekly report. It's also bad when all I can report is "kept on working on testing security, d-i, etc". There's some incentive to pad reports with unimportant stuff, you be the judge of how often I succumbed to it. It's also worth nothing that my employment contract specified that I also make monthly reports before being paid each month. I did this for secveral months, and then forgot about it. Since I kept being paid I guess the weekly reports were good enough, and the formality of collecting them into a monthly report was not important. Anyway, I also did this nice yearly report, which was not required anywhere. | - Working installation of Debian Edu based on Debian/Sarge within 2 | months. This was effectively acheived, although it got quite a lot better after the 2 months were up. The main things I contributed toward this were doing CD builds (and later, setting up daily and then on-demand CD builds), and also working on d-i and the debian-edu specific parts of the installer. | - Security issues in Testing should be uploaded and fixed at most 4 | days after the DSA for Stable is published. It would take a lot of historical research to determine how well this has been accomplished, and I have not gone back and done all the research, since fixing new security holes seems more important. I do know that there are currently only two DSAs that are not fixed in testing (one of them was released today (21 April)). For 79 DSAs, starting in January, I recorded whether the security hole was _already_ fixed in testing by the time the DSA was released. We accomplished this for 28 of the 79 DSAs. I also roughly estimate that for 50% of all security holes, an upload is made to unstable with high urgency within 2 days of the DSA being released, which should get it to testing within the specified 4 day period. I also estimate that of all the security holes in testing, only about 10% are covered by a DSA, and we manage to fix the other 90% nearly as quickly as the holes that are covered by DSAs. Also, probably at least a third of those holes do affect stable; many lesser and harder security holes never get a DSA published. Now that the testing-security team is operational, I think that a better criteria would be something like "New CANs/DSAs are processed and bugs filed within at least one day of their being released; and the number of known security holes in testing is kept below 30 at any time." We generally manage to acheive this in the testing security team. I will be giving a talk at DebCconf Helsinki about the tesrting security team, and I expect to have better and less off-the-cuff numbers for some of these things by then. | - The Debian Edu CD (for Woody and Sarge) should be installable at | least 3 days in the week with no errors detected by the runtime | test suite. Mostly achieved. Since this requirement basically meant I had to install debian-edu at least once each day to see if it worked, I ended up trying to automate the whole installation process (with expect and some nice server hardware donated by HP). Unfortunatly, some technical issues prevented me from fully automating the second stage install, so currently my test system only automatically tests the first stage install of debian-edu. We did have a few weeks where even the first stage wasn't installable 3 or even 1 days of the week. Over the past 53 days, which is as far back as my records go due to a disk crash, the first stage debian-edu install has succeeded 47 times. Second stage doesn't always do as well, and since it's only tested manually, by myself and others, I don't have any numbers. Aside: One useful offshoot of the automatic testing that this prompted me to set up is that it grew to be a fully automatic installation test lab for d-i on 7 architectures, running a total of 60 automated install tests a day in addition to the debian-edu install test. This turned out to be very useful in keeping d-i working on all those architectures as well as spotting many problems before they affected users. | - LTSP or a working comparable thin client solution should be | included in the Debian after 6 months. We have lessdisks, although as mentioned earlier, I had little to do with making this happen. And that's the end of the task list. In summary, I was not able to fully meet all of the goals, some were taken on by other developers, and some were only partially done. The tasks I had the best successes with were keeping d-i working, getting the debian-edu CDs building and at least partially working, testing, and forming the testing security team. Notable incomplete tasks include finding maintainers for all debian-edu packages in sarge, getting debian-edu patches accepted into Debian packages, and working on the skolelinux to debian-edu upgrade path. I am proud of the work I did manage to accomplish. I began this year's work as a Debian oldtimer who was not a user of skolelinux, and I think that this both influenced which tasks I did well on, as well as presented some difficulties. One difficulty is that I don't speak Norwegian; this really does cut one off from a lot of the skolelinux user community and some of the developer community. So does not living in Europe; I visited Europe three times this year, but only got to one developer's meeting. But these were not large problems compared to the problem of not having any prior experience with skolelinux. I learned as much as I could, but to learn some of it, one really needs access to a skolelinux classroom. I am still painfully aware of gaps in my knowledge. I'm sure that this led me to focusing on the bits of skolelinux/debian-edu that I did understand well, and the bits of my task list that didn't need a lot of prior knowledge of skolelinux. I think the lesson here is plain, if hiring someone who is not already actively working on this project, it's best to have tasks for them that do not need a broad and deep understanding of skolelinux, or you have to expect that it will take them quite some time to get up to speed enough to be able to take on everything. Of course I do think I've gotten past these problems enough over the past year that they're no longer big problems for me. I really don't know what the chances look like for my contract being renewed for another year; if it did get renewed I think we would want to change many of the goals and success criteria, focusing on continuing work on the things that I've successfully accomplished but that need containuing work (such as testing-security), and finding new goals that are a good match for my skills and the needs of debian-edu. -- see shy jo
Attachment:
signature.asc
Description: Digital signature