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

>> 1) Compiles and passes simple tests on all archs
>
> This is not reasonable to ask a single developer to do.

This is why you ask other developers to help. Major functionality
breakage should not be undertaken lightly.

>
>> 2) Retains m:n support for uniprocessor as an option
>
> This is an unrelated feature request. Given the reasons around
> switching from M:N to 1:1, I think the burden of making this work
> should be on the people who want it, not the people who want 1:1. I
> wrote the M:N support, and I'm not even bothered enough to keep it
> around.

M:N was workiing in uniprocessor _and_ being used. It's the
responsibility of the people who break functionality to resolve the
issues they introduce by breaking it.  The "feature request" is _very_
related, as all it asks for is "don't break what's working."

>> 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.
>
> This assumes that -current needs to work all the time.

It makes no such assumption. -current is expected to break, but as an
unitended consequence, not as a deliberate act by a developer. It
assumes that you wish to treat your user base fairly in return for
their willingness to test code for you.

> I'll repeat this: I don't agree. This is *exactly* what -current is
> for. Again, if this bothers you, wait for a release.

No. Working with known broken code, even in NetBSD, is what private
branches are for. Never committing code you _know_ is broken is a
fundamental part of maintaining a working relationship with your
users.

If you don't want users testing -current, by all means, do them the
discourtesy of commiting code you know you broke.  And then wonder why
you're not getting any test coverage.

It's a balancing act. If you treat users cavalierly, they go away
and current looses its value as a testbed.

Deliberately committing broken code treats them that way.