Michael Lorenz <macallan@netbsd.org> writes:

> It got removed from -current, AFTER 4.0 was branched so the first 
> release with the new threading code will be 5.0 which will probably 
> happen in 2008 or later. Unless you're using -current in whatever 
> product you're working on you have plenty of time to adjust and 
> whatever fixes you come up with will be useful for the 4.0 branch.
> I would understand such an outcry if a change like that had happened on 
> a release branch but - well - it didn't.

Guess who has to work in -current because the arm port maintainer
didn't commit the OMAP architecture in time for it to make the 4.0
branch?

The 'outcry' is in response to not one bit of brokenness from the
NetBSD foundation, but rather in response to a many month sequence of
brokenness that cumulated in the M:N straw breaking my patience and
making me sad.

This 'outcry' comes after now more than six months of coping with one
failure of the NetBSD foundation process after another. Port
maintainers that don't maintain their port; patches that no one
bothers to apply; months of being told one story when a different one
was happening; queries as to status of process going unanswered;
developers who neglect to mention that the patch they've been asked to
review is rendered moot by their arbitrary changes to the kernel;
lack of visibility into the foundation's technical decision making
that makes planning difficult; and now we can add to this meddlesome
people like Mr Simon intruding into issues of which they are
unfamiliar and agitating about topics of which they are unaware,
apparently for the simple reason that they are friends with the
developer who made the most recent foundation mistake that has affect
us.

Even if I have "plenty of time to adjust", that's missing the
point. Those of us developing for NetBSD should be consulted before
major pieces of functionality are removed from it.  It may well be
that after the consultation the piece will be removed anyway, but on
the other hand, it may well be that there was no need to remove it in
the first place -- which, in my very humble opinion happens to be the
case here.

Let me repeat that, as Mr Simon's "petty bickering" has obscured the
point again:

The NetBSD foundation's process for technical decision making is
broken. The break is that it fails to include others who are
developing NetBSD.  I brought this whole point up for exactly one
reason: I wish that the NetBSD foundation fix it's process. Technical
discussions should be held with a wider audience. People who are
changing the code that is about to be deprecated should be consulted
to see if they have a fresh view on the problem.

That's the whole purpose of this "outcry": Dear NetBSD foundation,
please improve the visibility of your process. It's broken. It's
preventing you from utilizing resources outside the foundation and
it's making NetBSD less attractive as a development platform to those
of us who need to base plans on reliable understanding of the
technology we intend to deploy.