> The rule you're forgetting is that, if Developer A is using part of a
> project and Developer B's changes keep introducing regressions in it,
> then Developer A ends up spending most of his time cleaning up these
> problems instead of working on what interests him.  The typical open
> source response of ``well, if you want it to work, then why don't you
> fix it yourself?  

gcc has exactly that rule. This only works if developer A is actively involved 
in development. If developer A reports that Developer B broke something 
within a reasonable timeframe then Developer B will generally fix it.

However if Developer A is doesn't actively participate in development (by at 
least testing, and reporting bugs), noone will notice that things have 
broken. If a port is so badly maintained that it doesn't even build for long 
periods of time this means developer C can't test their changes there even if 
they wanted to.

> I'm not your employee, so you can't tell me what to 
> do,'' is totally inappropriate in this case.  In this scenario,
> Developer B has effectively hired Developer A for $0/hr, and hired him
> to do the messy work Developer B doesn't want to do.  

This works both ways. It's IMHO equally unreasonable to expect Developer B to 
spend lots of unpaid time fixing messy, obsolete code that they're never 
going to need or use. This is especially true if Developer A (probably the 
only one with interest in or easy access to the resources to do the testing) 
doesn't bother reporting the breakage for several years.

> Developer A just  wants it to work like it did yesterday.  

That's easy. Just use yesterday's release.

What developer A actually wants is all the whizzy new features without having 
to put in any effort to make the bits they care about work with the new bits.

> I don't understand the coldfire issue at all.

Maybe you should. I don't believe any of the above discussion is relevant. 
NetBSD doesn't even support ColdFire. Part of of my my original proposal was 
that m68k and ColdFire are sufficiently different that for practical purposes 
they're separate architectures.

I think we've both made our opinions abundantly clear, so this will be my last 
response on this subject.

Paul