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