Re: Regarding the ULTRIX and OSF1 compats

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Sat, 16 Mar 2019 14:28:27 +0100
    From:        Maxime Villard <max%m00nbsd.net@localhost>
    Message-ID:  <17ba7752-793d-d352-09ef-c43676d2fc92%m00nbsd.net@localhost>

  | Ok. So you believe that dead wood should hold back all of the development
  | process?

No, but only if it truly is dead.   Just because you don't see the
utility does not make it so.

  | I believe you misread,

You're right, I did, I just skimmed the patch you made, and did not
look carefully enough.   But the point is unchanged.   There was a bug.
When it was reported it was fixed.   That's what's supposed to happen,
and isn't evidence of anything being wrong.

  | As I said, this is one example among others.

Yes, so you keep saying.   But those others are in one of three
groups.   Either they're like this one, and have now been fixed,
in which case they're irrelevant.   Or they have been reported,
and no-one is fixing them (which can happen for many reasons) in
which case you should just supply the PR numbers for all of these
problems, that might stir some activity around some of them, or it
might not.   Or you know of bugs that no-one else knows about, and
you're just sitting on.   That would be all on you.

  | And yes, this bug was introduced because the API was being replaced,
  | and yes, the person who committed this code likely did all he could
  | to make sure no bug was introduced, and yes, he did still add a bug
  | because a certain number of these compat layers are dead wood that
  | can't be tested, not even by those who claim they are so important.

But this one (the one above) is in code that is apparently not dead
wood, and that people do use.   But that people use code does not mean
that every bug is going to be encountered - bugs often stay undetected for
a very long time, just because no-one happens to do whatever it takes
to trigger them.

  | In fact, all of your "rules" were respected, yet the bug still inevitably
  | came in. Why is that?

Because bugs happen.    ALways have, always will.   The only way to
avoid bugs in NetBSD would be to shut it down.   Delete everything.
Then it would have no remaining bugs.   It wouldn't be useful though.
But it would end this discussion!


  | This is what happens with dead wood, you just don't want to face it.

But, apparently, COMPAT_ULTRIX isn't dead woood, and people still use it.
And that's what the one bug (now fixed bug) you have cited, that I have
seen, was in.

  | And I'm not even speaking for myself, you just have to see the answers to
  | "does anyone use compat_xxx". You can even try as hard as I did, with
  | COMPAT_SVR4, ask on several different mailing lists, repeatedly, over and
  | over. No one ever answers.

And most likely no-one ever will.   You cannot get answers that way,
the people on our mailing lists mostly only care about this week's (or
this year's anyway) code, and wouldn't consider running anything that
didn't come from available sources.

But NetBSD (and all the other systems) are used by more people that that.
I know of several NetBSD users who would never go anywhere near any of
our mailing lists ... the closest they ever come is looking at the web
site from time to time to see if there's been a new release.

The only way to find out whether something is being used is to remove
it from the default config, but leave it relatively easy to turn back
on again (and ideally ask - where it is to be enabled - for anyone who
needs it, and enables it, to send e-mail to xxx%netbsd.org@localhost)

That was done with the removal of the ISA graphics card support (I mean,
who uses ancient PCs, new ones are cheap, and much better...) but then
it turned out that someone still did.

  | If UVM was of questionable utility,

Everything is of questionable utility.   We used to not have UVM
so we know it is possible to survive without it.

Note I am not questioning keeping that, just your certainty that you
know everything that is required, and useful, and that everything else
is "dead wood" and should be deleted.

  | I stated my point clearly and logically, about why certain things have
  | legitimate reasons to go away,

Sorry, I must have missed that.   All I ever seem to see is that xxx is
unmaintained and full of unspecified bugs, and that obviously no-one cares,
and so we should delete it.    That's not an argument for anything.

Also note I am not arguing for keeping anything in particular, just
against your reasons for deleting it.   If some functionality really
is of no further use (and some of the drivers that were recently removed
seem to be in that category) then by all means, we should remove it.

But that you don't use it, and no-one on the mailing lists admits to
using it, does not mean no-one uses it.   You need to move much more
slowly.

I'd suggest perhaps for something that we believe might be of no further
use, then if it is userland, we just unlink it from the build, but leave
the sources in the tree, with a mk.conf option to cause it to be included,
and if it is kernel (like most of what you're concerned with) then we
just remove it from the default kernel config.   And we do that for -9
(whatever is the next release after the issue is raised).   Then if by the
time we're getting ready to release -11 (nb: not -10, not everyone updates
to every new release, and in fact waiting for -12 might be safer) - that is,
2 or 3 major releases after that first step, if no-one has complained, or
asked why it isn't (seemingly) available any more, we might delete the old
code.  If there are questions/complaints, then we perhaps (in addition to
telling people how to restore the omitted functionality) restore it in
the next point release(s).

Yes, this makes it a long slow, and tedious process (involving a bunch of
additional work) to delete something - but so it should be.  Someone spent
a lot of time making the thing you want to discard work in the first place.

kre