Was: Re: Moving virecover to ~/

[Izaac <izaac%setec.org@localhost>]

I had written this reply nearly a year ago.  But I sat on it.  Now,
though, I find myself so pissed off with the changes in release
engineering/support, issues with the 8.0 release itself, and with the
recent crop-up of this /bin/sh issue that I figured I'd dig it up and
send in hope that it might cause someone some level of reflection:

On Wed, Nov 15, 2017 at 08:46:17AM -0500, Izaac wrote:
> I'll reiterate to anyone looking to muck about in this way:
> 
>   Stop.
> 
> You need to think very, VERY hard about the consequences of the
> slightest variation in these components.  They are the intersection of
> disaster: vital functionality, arcane code, no real test suite, highly
> visible in failure, no appreciable benefit.  The risk profile screams
> "stay away."

On Wed, Nov 15, 2017 at 02:34:36PM +0000, Christos Zoulas wrote:
> We find issues, we propose solutions, we discuss them, we reach consensus,
> we change things or leave them alone.

We've been doing an awful lot of changing.  Is there a general
understanding that changes mean work for other people?  Is there a
recognition that the deployment of NetBSD in any kind of production
capacity requires huge amount of maintenance effort -- which is only
exacerbated by these kinds of re-arranging of the deck chairs?

> Sometimes we make things better, others worse. Time tells. Nevertheless,
> leaving things alone because nobody understand them and everyone fears them

You're confusing fear with responsible caution.  You're confusing fear
with a desire to maintain stability.  You're confusing fear with
experience.  

> does not serve anyone in the long term. And if you want a system that never

It's fitting that you want to bring up the notion of "long term,"
because changes of this type are completely antithetical to long term
service and support.  I have NetBSD 5.1.5 still in production out there.
Why?  Because the amount effort necessary and risk associated with
accomplishing an upgrade is so imposing -- and the benefits are so
miniscule -- that it's not economically viable.  It makes more sense for
me to leave them alone, because these changes are of no benefit.

But why don't we discuss the real long term by addressing goals?  Which
of the project goals, specifically, does mucking around with virecover
or the system scripting shell advance?

- provides a well designed, stable, and fast BSD system,

  Software which has been functioning successfully for a few decades is
  at least successfully designed, if not well; making a change like
  this is the opposite of stable; and nothing's getting faster.  So no
  goal progress here.

- avoids encumbering licenses, 

  None here.

- provides a portable system, which runs on many hardware platforms,

  None here.

- interoperates well with other systems,

  None here.

- conforms to open system standards as much as practical.

  I'll readily admit that a couple of the things for /bin/sh to make it
  more POSIX-y may well be worth it.  But there's also a thread going on
  right now about changing how -x works.  You, at least, made the
  responsible suggestion of a separate option.  But why is this even on
  the table?  If /bin/sh -- whose primary purpose in life is the
  execution of /etc/rc and other system maintenance scripts -- is
  insufficient to your purpose, use a different shell!
  
So, we're not advancing stated project goals.  Are these bug fixes?
In the case of virecover, I see some lovely patches from snj.

So, please, justify to me the benefit -- any benefit -- to these
changes.

I can practically guarantee that if you are able to come up with
anything at all, it pales in comparison to the risks and the burden to
the existing installed base.

> changes, you can chose a snapshot anytime....

"Fork off," eh?

Well, so can Mr. Elz.  The difference here is that if he forked off, the
rest of us would not be burdened by his private changes.  He can go
Poettering around his fork all he likes.  Or put an elzsh in pkgsrc.  Or
even in base.  Perhaps "time [will] tell" us that it is indeed a
suitable and desirable replacement for our existing /bin/sh.  I'll lay a
shiny nickel on the table which says that no one will go running through
/etc/rc.d replacing #!/bin/sh with #!/bin/elzsh to get these "features"
or fix any of those "bugs," and that not a single new user will be
garnered by these changes.  (Although you seem almost eager to push
someone out over them.  Hmm.)

If only Yuuki Enomoto enjoyed this kind of support from you and Thor for
his basepkg work; then I COULD actually pin binaries in a consistent
manner.

(Is there any interest in making changes in that arena, i.e. deployment
and operational management?  "Nah.  Let's screw around with ls(1)!"  I'm
sure that's next.) 

-- 
. ___ ___  .   .  ___
.  \    /  |\  |\ \
.  _\_ /__ |-\ |-\ \__