Are you trying to teach the OpenBSD devs how to write good software? Unix software?
Really? REALLY ????? On Mon, 2023-09-25 at 21:11 +0000, Eponymous Pseudonym wrote: > 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 <rudolf.leit...@gmx.at> 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 !
