Standardisation, specification and documentation as a starting point for software creation is a normal, reliable and mandated (formally) methodology used everywhere from business to scientific, industrial, medical and military applications. It is not only normal but expected and even required that amateur free and open software follow the same processes and procedures as professional modelling and implementation, especially on historically significant long term projects that are also programming languages and interpreters.
It's not a surprise to you, everything in UNIX is a compiler construction reuse tooling and a small (and large) domain specific languages. That is the essence of the system. OpenBSD is a descendant of UNIX, not a free walk in the green pastures of experimental shareware. Now, let's get back to more productive time and space utilisation, kids, good ideas.. third party re-imports are waiting their normalisation and stabilisation to robust and reliable distillations of core "base and extended" system modular componentry. Re-read the long version of the previous post after some specialised references again, and you will see and understand what I outlined clearly. https://en.wikipedia.org/wiki/Software_crisis?useskin=vector#mw-content-text https://en.wikipedia.org/wiki/Component-based_software_engineering?useskin=vector#History https://en.wikipedia.org/wiki/List_of_software_development_philosophies?useskin=vector#Rules_of_thumb,_laws,_guidelines_and_principles Thanks for the discussion and support, I've said my points and think we're in accord and agreement on all details referenced. On 9/25/23, Rudolf Leitgeb <[email protected]> wrote: > If you document a switch, you are basically required to keep that > functionality around forever. Given that the OpenBSD devs don't like > these --options all that much, I don't see that happening. Submitting > a patch won't change that. > > IMHO there's nothing wrong, if software can do more than its > documentation shows. It's not like it breaks documented behavior. > > On Mon, 2023-09-25 at 20:58 +0200, Marc Espie wrote: >> Don't rant that long. >> >> Sometimes, documentation and code get out-of-synch for a lot of >> reasons. >> >> - trying out stuff and documenting later. >> - plain forgetting to update the documentation. >> - having some stuff for a transition period, and then killing it. >> >> Your point that stuff that stays around, should ideally be >> documented, >> is a good point. >> >> Now, you gotta realize that people have limited time to do >> everything. >> >> In general, patches are welcome. >> >> In my long tenure on various tools, I've learnt that documenting >> stuff is always always a good idea: if you get a new feature BUT >> you can't explain it cleanly, then you should go back to the >> drawing-board !
