Eric Haszlakiewicz <erh@swapsimple.com> writes:

> If you'll refer to Andrew's email announcing the merge, you'll see
> he claims that it DID pass a minimum of tests.

He also said he knew it was broken on a bunch of architectures. It's a
bad practice to check in code you _know_ is broken, especially when
there's no rush.

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

Doesn't compile on ARM. Andrew knew it wouldn't compile on ARM when he
checked it in. No ETA on when it'll even compile on ARM.

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

One of the things that we used to sell NetBSD to our management is
that we believed that one of the advantages of having our code in the
CVS tree would be that we could count on fundamental functionality not
being broken without the community fixing the code. This fiasco with
m:n threads has proven that not to be true and is causing us to
seriously reevaluate the risk involved in using NetBSD.

But in answer to your question, had we been asked, we might even have
fixed SA in general.

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

No. The unfortunate thing is that someone thought there was an
artificial for rushing this code into the tree. Andrew claimed in his
email that the fixes for the missing architectures were in the
pipe. Knowing that, there was no reason to jump the gun.

We're not talking about functionality that couldn't wait for a few
weeks to get into current.

> 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 far as I can tell, he's washed his hands of solving the problems he
introduced into libpthread. He's written an email saying that his
changes "couldn't possibly" have caused a particular problem and he
_still_ hasn't gotten back to me on the patch I sent him weeks ago.

As far as I know, he's not picked up the slack on ARM, although I
understand someone else has, after we complained.

As far as I know, he's not picked up the slack on restoring M:N
uniprocessor threading, which we use heavily.

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

Dear world, despite the complete lack of participation by the port
maintainer, EVBARM is an _active_ port. Please to not be breaking it
gratuitously in the future. Kthx.

I want to make something perfectly clear. Several people have
indicated that I'm only complaining out of selfish commercial
interest. That's about as far from the truth as possible. Had my only
interest been commercial, I would have simply grabbed a NetBSD
snapshot and not contributed anything back.

We went to a lot of internal hassle to even get permission to
contribute. We had to justify the expenditure of resources on the
extra overhead of keeping in sync.  We worked hard to push an new
architecture port out. We have done everything we could to work with
this community.

In return, port maintainers haven't responded, patches haven't been
applied, long periods have passed without any response to queries
about status, and now code that breaks our world is dropped knowingly
broken into -current.

My _commercial_ interest at this point would be to stick with the
snapshot we've got, withdraw the OMAP port, and not bother to send any
more bug fixes.