"Nathan J. Williams" <nathanw@wasabisystems.com> writes:

> Bucky Katz <bucky@picovex.com> writes:
>
>> Based on a lot of experience with this sort of change, it's my
>> opinion that you'll get to a stable newlock faster that way than by
>> dropping the changes into current and trying to fix them there.
>
> Based on my experience introducing the SA code in the first place -
> much like the newlock2 code, avaliable on a public branch for quite
> some time - I disagree. Getting it on the head is the only practical
> way to get testing coverage on all of the architectures and in
> different runtime environmnents. Your approach, in a volunteer,
> distributed project like this one, would result in code such as SA or
> newlock2 never being introduced.

I agree that you have to put it in head and live with some breakage
before you'll get test coverage.

What's wrong here is that it shouldn't go into head until it at least
passes a minimum of tests off head.

My approach, in a volunteer, distributed project like this one, is
commonly used and results in a lot of things making it into the tree.

> 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.

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.

In fact, as long as you know it's broken, you shouldn't introduce it,
even into current.

Given that he knew that newlock2 was broken, Andrew should have never
committed it.  You commit feature breaking changes _after_ you've
fixed all the bugs you can find on your own, not before.