[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RunDinstallHourly

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

Reply to: