Testing transitions before uploading to unstable
You're Devon Deppler, the maintainer for the Xyzzy set of packages, a
total of a dozen packages. They're important and influential: about a
quarter of the entire archive depends on the packages in one way or
another. You have lots of users.
Now upstream comes up with a new version, and changes some things in
fairly fundamental ways. They're good changes, and they need to be made.
The old way of things has been causing some problems already. The
problem is, the changes aren't backwards compatible and they will break
other packages. Some packages won't be building anymore, and others
won't install or operate properly until they're updated.
Your mission, should you accept it, is to make things happen so that
when you upload the new packages, as little breaks for as short a time
as possible. Should you, or any of your co-maintainers, fail to be
perfect, the bug tracking system will be flooded with bugs and people
will be calling you names.
Sound familiar?
Transitions are going to happen in Debian, but we don't seem to have
good tools to deal with them. It strikes me that it would be cool to
have something like this:
* You upload your new packages to a staging system.
* A fully automated tool upgrades an existing system (a chroot,
a Xen instance, or whatever) to your new packages, and reports
if all went OK. It also runs automated tests to see that
everything works, before and after the upgrade.
* If that worked, it re-builds your packages and everything that
build-depends on your packages and reports results.
* If there were any problems, you can fix packages and try
again. As many times as you need to. You can also include fixed
versions of other packages to test them, too.
In my vision, this system would have enough computing power to be able
to iterate even a large transition at least once per day, maybe more
often.
All the components for this already exist. We have autobuilders, we have
upgrade testing, we have a tool for automated testing of package
functionality. There is, in theory, nothing to stop anyone from doing
this on their own system (and I assume some have done so), but it would
be so much easier to not have to master every component tool yourself.
Also, since this requires a lot of computing power to be efficient, it
is not something people who work only on an old laptop can do very well.
I think that if we created a centralized system for this (or possibly a
distributed centralized system), it would be possible to make it fast
enough to be quite usable.
I think this would be possible to do. I don't have time for it myself,
at least until Debconf, and I don't know some of the components
(especially the buildds), but I suspect that for someone who does, this
would be relatively straight-forward to assemble together. Anyone
interested?
--
Programming should be fun, otherwise you're doing something wrong.
Reply to: