On Tue, Jan 04, 2005 at 11:16:44PM -0800, Ken Bloom wrote: > On Tue, 04 Jan 2005 18:04:37 -0800, Steve Langasek wrote: > > 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. I don't know about you, but I'm usually awake for at least 16 hours at a time, which gives me a 1 in 3 chance of being awake for both dinstall runs if the timing is random, and probably higher than that if the timing is "optimum". But I'm not sure why I would care about being awake through both of them anyway; one of the immediate benefits of having two dinstalls a day is that everyone would be awake to see at least *one* of them, which isn't the case today. Being able to work through one dinstall in a given day is enough to let a developer upload, wait for feedback, and fix -- they wouldn't be able to see the results of the *fixes* until the next day, but if they don't know if they've fixed the bug, they bloody well shouldn't be uploading another package to the archive and stressing the autobuilder network: that developer needs improved quality assurance practices, not more frequent dinstall runs. :P And it's not like users want more frequent updates, either. Once a day is plenty often to be fiddling with apt-get; many sid users don't update nearly that often, after all. The exception is when something breaks, and you need a fix yesterday, in which case you don't want to wait for the fix to be apt-gettable from your mirror anyway: you grab it from incoming, or get a test deb from the maintainer before he's uploaded, if it's that important. Hourly dinstalls aren't going to improve on the usability of this when the mirror pulse is likely to take at least an hour to reach the edges. There are really very few concrete benefits I can see to increasing the dinstall frequency, but one in particular is to speed up debian-installer testing. Most other bugs don't require a full dinstall cycle to give people a good idea whether they've been fixed, but the installer builds out of the archive, which means that verifying the fixes for certain bugs *does* require a dinstall pulse followed by a d-i and CD build. So stepping this up to a higher frequency than once a day can help here, but stepping it up so that dinstalls happen more frequently than CD builds can be completed does not. > > 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. - testing changes are clocked by the same mirror pulse as unstable - if this is supposed to be a change that helps the release, it is important to consider the effect it will or won't have on testing, since that's the suite that's actually used for staging stable -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature