Date: Tue, 30 Jun 2009 23:01:45 -0500 From: Robert Noland <rnoland@FreeBSD.org> To: Ken Smith <kensmith@cse.Buffalo.EDU> Cc: src-committers@FreeBSD.org, svn-src-all@FreeBSD.org, marc@msys.ch, svn-src-head@FreeBSD.org, mbr@FreeBSD.org, "M. Warner Losh" <imp@bsdimp.com> Subject: Re: svn commit: r195200 - in head/usr.sbin: . wake Message-ID: <1246420905.1855.19.camel@balrog.2hip.net> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-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 <rnoland@FreeBSD.org> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1246420905.1855.19.camel>