Date: Tue, 7 May 2002 10:24:40 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.org> To: Maxim Sobolev <sobomax@FreeBSD.org> Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/etc rc.serial Message-ID: <Pine.NEB.3.96L.1020507101525.76283E-100000@fledge.watson.org> In-Reply-To: <3CD7DE3A.B7E3E60C@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 7 May 2002, Maxim Sobolev wrote: > Robert Watson wrote: > > > > On Tue, 7 May 2002, Maxim Sobolev wrote: > > > > > sobomax 2002/05/07 00:47:17 PDT > > > > > > Modified files: (Branch: RELENG_4) > > > etc rc.serial > > > Log: > > > Revert 1.14.2.4 - I forgot that we are frozen. Sorry. > > > > > > Revision Changes Path > > > 1.14.2.5 +2 -2 src/etc/rc.serial > > > > Forgetting is an even worse excuse than not noticing. As a general rule, > > if you can't bother to keep track of whether we're in a release freeze or > > not, don't even bother committing to the RELENG branches. Knowing about > > the release schedule is a *basic* requirement of working on a production > > operating system, especially on the release engineering branch. > > We all human beings and we all make mistakes from time to time. I don't > believe that those 10 minutes during which change was in the RELENG_4 > branch could hurt something. In the last three days, we've had an unapproved MFC of an entire PCI driver and more during a code freeze. The basic message here is exactly what I said: As a RELENG_4 developer, you are responsible for keeping track of the status of the tree. We (the release engineeering team) announce code freezes months in advance, weeks in advance, days in advance, and at the actual point the freezes begin. We maintain a release engineering web page with the schedule easily accessible. We even respond publically to un-approved MFC's indicating that they are such, and asking that people go through the right process to MFC during a code freeze. This is a production operating system engineering team. We write operating systems that real people use in production. We have well-established and documented procedures for how this goes on. Sure, it's a simple mistake, and we're all happy it could be corrected so easily. The worrying thing is not the individual mistakes (which, as has been pointed out, happen sometimes), it's the trend of mistakes. These mistakes need to stop happening, because they're easy to prevent, and they reflect underlying carelessness regarding how the project runs. As I said, knowing the release schedule is a *basic* requirement. The message I sent to you was more in response to the trend than your individual mistake, but the statement stands, and I think the message is clear. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1020507101525.76283E-100000>