Debian development is a cycle guided by the metronome of the daily archive update (aka "dinstall") run and mirror sync. Each day developers upload new packages and wait for the metronome to tick, the mirrors to update, the users to test out the changes and report back with new bugs. This effectively limits us to one test cycle per day.
Generally reducing the period of a test cycle will speed up software development, which has the potential to let us do more between releases, or speed up the Debian release cycle.
So why not update the archive and the mirrors hourly? Or to start off with, twice a day? It's hard to accurately predict all the effects this would have though we might get some indications from Ubuntu, which already does this.
Update: As of December 2008, dinstall runs four times a day.
Pros:
- Fast turnaround time on finding out that a new upload introduces a bug and getting it fixed and available to wide user testing.
Cons:
- Added load on ftp-master and on the mirrors.
- Possible unpredictable negative consequences.
- Developers might possibly think less before releasing if they know they can get any fixes for bonehead mistakes in within a couple of hours when someone else notiecs.
Notes:
This is something I particularly want for the DebianInstaller. It's much easier to send someone a regular deb for testing than it is to locally build a debian installation image containing a fixed d-i udeb. Moreover, it can take up to three daily cycles for some d-i changes to filter though to a state that they can be easily tested for users, so it's not uncommon to tell someone who reports a bug on d-i that "I've fixed that in svn; try again next Wednesday". Which slows things down a lot, and increases the probability that by next Wednesday the user will have worked around the bug and put their machine in production, and be reluctant to reinstall it. -- JoeyHess
If it's really technically easy to make this change, then I would do it now (before Sarge is released), maybe ramping up to twice a day for a week then 4 times a day if that works, and undoing the change if it causes problems. --?KenBloom
many pages (like packages.qa.debian.org) also live on the archive beat and are already outdated very often. we should switch most of these from regularily regenerated to genereated-when-requested or generated-when-something-changes so they are able to reflect the speedup in archive pulse (debian@2000rpm
-- robert Thinking out loud: This proposal assumes that users will upgrade systems more often or that bugs are likely to be detected by anyone. The intention of the proposal is to increase the "cross section of bugs", that is, make bugs more likely to get noticed b y someone. In theory if the mirror pulse happens at time T, and it takes a time dt to get to the mirror, the user can "see" the new package starting at time T+dt. Now, if this is somehow compatible with the time the user performs a daily upgrade (only a handful of people are crazy enough to make fully automatic upgrades from unstable), that means, the user does his daily upgrade at some point between T+dt and T+dt+1/f (where f is the frequency of the pulse), then the user is going to see the bug and report it. Now, this assumes that the bug is equally likely to be seen by anyone. Some bugs require special conditions to be seen, and these tend to migrate to testing unnoticed. If users in this group perform one daily upgrade, we are back to more or less [T+dt,T+dt+1d]. The other implicit assumption I see is that people are going to be uploading more often. There are some Joey-like developers, who perform several uploads a day. This proposal gets their work to the mirrors faster. There are other developers like myself, who upload once every so many days. For this group things don't change much. All in all, I see some benefits, but not the ones the proposer sees. -- MarceloMagallon
This proposal is also discussed on debian-devel@lists.debian.org. See http://lists.debian.org/debian-devel/2005/01/msg00141.html for that discussion
Back to ReleaseProposals