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.) -- . ___ ___ . . ___ . \ / |\ |\ \ . _\_ /__ |-\ |-\ \__
