From owner-svn-src-head@FreeBSD.ORG Wed Jul 1 04:01:53 2009 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19F071065673 for ; Wed, 1 Jul 2009 04:01:53 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id C89CC8FC1E for ; Wed, 1 Jul 2009 04:01:52 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.4] (adsl-156-4-82.bna.bellsouth.net [70.156.4.82]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n6141oVe004843 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Jul 2009 00:01:50 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Ken Smith In-Reply-To: <1246413402.70460.23.camel@bauer.cse.buffalo.edu> References: <0E6D4FB2-A485-40ED-A856-ACC311A90EFE@msys.ch> <20090630.141340.289711551.imp@bsdimp.com> <7B9C309F-63E3-4CB8-9871-DE2DEE010096@msys.ch> <20090630.164009.2130804684.imp@bsdimp.com> <1246413402.70460.23.camel@bauer.cse.buffalo.edu> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-GaeRJNBFhIAdEA5142+i" Organization: FreeBSD Date: Tue, 30 Jun 2009 23:01:45 -0500 Message-Id: <1246420905.1855.19.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.2 FreeBSD GNOME Team Port X-Spam-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,RDNS_DYNAMIC, SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: src-committers@FreeBSD.org, svn-src-all@FreeBSD.org, marc@msys.ch, svn-src-head@FreeBSD.org, mbr@FreeBSD.org, "M. Warner Losh" Subject: Re: svn commit: r195200 - in head/usr.sbin: . wake X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 04:01:53 -0000 --=-GaeRJNBFhIAdEA5142+i Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2009-06-30 at 21:56 -0400, Ken Smith wrote: > On Tue, 2009-06-30 at 16:40 -0600, M. Warner Losh wrote: > > I hate to be blunt, but this leaves a bad taste in everybody's mouth, > > even if at the end of the day you get your way. >=20 > Translation: I did it again. I hate it when that happens... :-( >=20 > Two things happened here that were a bit unfortunate, and Marc/Martin > (most likely unintentionally) tripped over it. >=20 > The first thing that left a bad taste in some peoples' mouth is this new > thing got approved past the point I had said many times was to be the > end of new things getting added. But people complained the warnings I > had given were buried in messages that had too much other information in > them instead of short and to-the-point messages. So deadlines for a few > things got extended in short and to-the-point messages yesterday and > this pending request fell into one of those categories. If you missed the deadline because you chose to skim messages from the release manager, then so be it... If people have work that they want to get into the release, then they should be paying attention to mail from re@. I know that I have work that I would have liked to gotten in, but complications arose which made it obvious that resolving them within the remaining time before the freeze was not practical. > The second thing that left a bad taste in some peoples' mouth is that > this apparently (strictly judging by the fallout discussions) didn't get > as much peer review as some people would have liked. Normally some > level of discussion happens on some public mailing lists (not private > email among a few potentially interested parties). And even after that > happens and the commit gets made there is some time for fallout > discussions to happen. Depending on the results of those potentially > lengthy discussions it might wind up being backed out. But because of > the stage of the release cycle we're in me having approved this can be > viewed as short-circuiting the normal public review because odds are it > will wind up staying despite some peoples' opinions due to the stage of > the release cycle we're in. >=20 > That second thing is one of the things that I think we're stuck with as > part of the release process, but I really need help from you folks on. > It's very much like the rant I made about the commit requests. And like > I said above I fell for this before, during the 7.0 release cycle. > During that release cycle it resulted in a rant with the subject line > "I'm not Head Dictator In Charge". People complain if we lock out *all* > new additions, even ones as relatively simple as a new command, too > early in the release cycle. So we *consider* allowing new stuff that > truly shouldn't impact the stability of the pending release until right > around now in the release cycle. But we need to be able to trust that > if you send in a commit request for something new like this that you've > already done the peer review type stuff. RE approval for something like > this doesn't trump normal peer review. The alternative is to flat out > lock out *all* new stuff no matter how seemingly simple it is earlier in > the release cycle just to avoid the problem that maybe someone will try > to sneak something through without sufficient peer review. A feature freeze in my mind is exactly that. re@ should be approving bug fixes only. No new work should be allowed beyond the freeze date. There is always the next release. That or people should have been paying attention and gotten things into the tree on time with appropriate review. robert. > Thanks... --=20 Robert Noland FreeBSD --=-GaeRJNBFhIAdEA5142+i Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAkpK36kACgkQM4TrQ4qfROOAsACfYTofk+4WURZkDUFfXDpUyAm1 YsAAn0eGo0hYhzJ4+p9pib0I2FgcmSLh =jTnv -----END PGP SIGNATURE----- --=-GaeRJNBFhIAdEA5142+i--