On Tue, 04 Jan 2005 18:04:37 -0800, Steve Langasek wrote: > On Tue, Jan 04, 2005 at 08:08:47PM -0500, Joey Hess wrote: >> Ken Bloom wrote: >> > http://wiki.debian.net/?RunDinstallHourly (part of the >> > ReleaseProposals topic on wiki.debian.net) discusses the concept of >> > speeding up the release process by running dinstall hourly instead of >> > once per day. This seems (to my amateur eyes) like a technically >> > simple change to make even before we release Sarge (barring any >> > unforseen consequences). Would it be possible to start testing this >> > proposal out now by increasing the frequency of dinstall, perhaps to >> > once every 6 hours until release? > >> I've talked about this with James Troup before. He seemed pretty >> receptive to speeding it up to something like twice a day, didn't seem >> to feel it would hit the mirrors much worse. It's possible he may still >> be waiting on SCC splitting up the base set of arches or the like before >> revisiting this.
Who's SCC? If there's no technical *requirement* for this to happen first, we should go ahead with speeding up this up, precisely because it's such a good time to test its effects, both positive and negative. (Positive effects won't be so noticable right after Sarge releases) I'm assuming it would be a really easy change to revert if it has negative effects. >> (BTW, please note that when I or this proposal talks about the "dinstall >> run", we're using the circa 1998 definition that includes "mirror sync". >> The dinstall program itself aready runs every 15 minutes.) > > Twice daily seems more reasonable to me than hourly; Why? If you run it only twice daily, then the developers who are awake at one run will probably be asleep at the next, so there's still essentially a whole day's lapse before a developer can fix anything. I'd say a minimum of 4 times a day lets a developer see the result of his changes before the next time he goes to sleep. But the attraction of hourly is that a developer can see feedback from his changes within a couple of hours, and a developer may be able to clean up any bugs people noticed in the same sitting that he introduced them. > for release purposes, > another factor is how often britney runs, since that's what triggers > changes in the testing suite. Doubling the frequency of britney runs > seems reasonable to me, but hourly would surely be overkill considering we > would still want to keep the waiting periods as they are now. The concept of RunDinstallHourly was supposed to be a more unstable-oriented approach. > Anthony Towns has been playing with the testing scripts this week, giving > the release team the ability to do by-hand runs of britney now. This > gives us more flexibility in catching our own oversights that would > otherwise push bits of testing improvements back by 24 hours at a time. > This has already directly contributed to getting KDE 3.3 into testing as > soon as we did -- if the dip in the sarge RC bug count is any indication, > this looks like a step in the right direction. -- I usually have a GPG digital signature included as an attachment. See http://www.gnupg.org/ for info about these digital signatures.