Date: Mon, 6 Aug 2001 23:56:47 -0400 (EDT) From: Chris BeHanna <behanna@zbzoom.net> To: FreeBSD-Stable <stable@freebsd.org> Subject: Re: Updating RELENG_4_3 Message-ID: <Pine.BSF.4.32.0108062352400.76089-100000@topperwein.dyndns.org> In-Reply-To: <20010807131205.L506@gsmx07.alcatel.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 7 Aug 2001, Peter Jeremy wrote:
> On 2001-Jul-30 01:43:44 -0600, Warner Losh <imp@harmony.village.org> wrote:
> >In message <Pine.BSF.4.32.0107292349440.7697-100000@topperwein.dyndns.org> Chris BeHanna writes:
> >: If the suggestion, "leave a small commit-free window around
> >: midnight UTC" is adopted, then you could use -D "00:00:00 UTC" and not
> >: have to worry (although you'd have to translate that to
> >: "[cc]yy.mm.dd.00.00.00" format for cvsup to process it).
> >
> >Two minor problems:
> >
> >1) 00:00:00 utc is the middle of the late afternoon/early evening in the
> > US. A more traditional quiet time is 3am MxT time (GMT-5 or -6
> > depending on the time of year). That's 2am on the pacific coast
> > (just after most people tend to stop committing there) and
> > 8am in the uk/europe (just before most people start committing
> > there). Traditionally, the tree is quieter then. This would be
> > 07:00:00 utc.
>
> 0700UTC is mid-afternoon to early evening for Japan and Australia -
> which would probably annoy committers here. It might also annoy the
> Russian's and similar areas (I think they have moved their clocks to
> be closer to LMT rather than use European time). Basically, given a
> global development community (such as FreeBSD has), you're not going
> to find a time that doesn't inconvenience some part of the community.
That's true, but Nihon-jin, Aussies, and Russians take dinner
sometime, no? :-)
> In any case, how big a window do you specify? Someone might start a
> commit with what seems like plenty of time to space, but because
> everyone else had the same idea, freefall is very slow. Or maybe
> the Internet has a hiccup and your `quick commit' drags on forever.
As long as the window is carefully observed, it needn't be longer
than a few minutes. Now, if we want to leave some margin of safety,
we might want fifteen minutes on either side of the target time of
day, and let people use their own best judgement about whether or not
they can finish the commit that they started prior to the cutoff
time. Committers' best judgement seems to work pretty well.
Inevitably, there will be the occasional commit that stretches
through the window, but that should be the exception, not the rule.
At the very least, this practice would increase the likelihood
that an update at the target time wouldn't occur mid-commit.
--
Chris BeHanna
Software Engineer (Remove "bogus" before responding.)
behanna@bogus.zbzoom.net
I was raised by a pack of wild corn dogs.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.32.0108062352400.76089-100000>