Subject: Re: Please Revert newlock2
To: Bucky Katz <>
From: Eric Haszlakiewicz <>
List: tech-kern
Date: 02/17/2007 21:46:12
On Sat, Feb 17, 2007 at 03:27:00PM -0800, Bucky Katz wrote:
> What's wrong here is that it shouldn't go into head until it at least
> passes a minimum of tests off head.

If you'll refer to Andrew's email announcing the merge, you'll see
he claims that it DID pass a minimum of tests.  (current-users, 
Thu, 8 Feb 2007 15:20:15 +0000, <>)

> "Nathan J. Williams" <> writes:
> > Fundamentally, -current being broken is something you should expect
> > and be willing to roll with. If you would like the bugs shaken out
> > first, then please wait for a release.
> Fundamentally, you've missed a state. There's "far too broken",
> "broken", and "less broken."  If you introduce "far too broken" code
> into current, your desire for user testing backfires as people move
> away from it because it's too unstable.

From what I've seen, the code _isn't_ "far too broken".  People have
been able to use it, test it, report bugs with it, and those bugs 
have been quickly resolved.

> It should be a ground rule of any project that you don't introduce
> code if you know it breaks architectures and you supposedly have those
> fixes coming.

Except that it is much easier for people to help with those fixes when
the code is on -current.  If Andrew had instead asked for people to
help get this working on the newlock2 branch, would you have taken the
time to get a copy of that branch and work on it?  The unfortunate
fact is that the people working on NetBSD have limited resources
and many people who would be willing to try things out in -current
don't have the time or motivation to go through the trouble of building
a separate branch.  (I know I certainly don't)

If Andrew had merged the newlock2 branch, said "here you go", and washed
his hands of it, then we'd be in a different situation.  But developement
appears to be actively progressing, bugs are getting fixed, and I'll
bet the case that you care about (e.g. the arm build) build be corrected
soon, and far sooner than if the code had not been merged.

As an added bonus, merging early makes it clear which ports have someone
using them actively enough to complain. :)