Re: RunDinstallHourly
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.
Reply to: