any problem going from 9.x (don't laugh) to 11 directly?

C Gray frankfenderbender at council124.org
Thu Feb 15 19:06:25 UTC 2018


Thanks much for the release stage info, Polytropon.

Processes are difficult to see, more so than code or issues based in "the repeatable".
They're harder to establish, and thus, w/o available documentation, to describe since it has no compiler's warning/error messages.
Issues are the most visible but require the code and the processes and the documentation, which is why I ask.

[Note: any greatness of 'man pages' ought to be always incorporated into the general published (ASCII or paper) documentation, perhaps in a note-referenced Appendix section of the 'man' pages at the end of the published manual. It's a task, but then, it can just be pulled into the published as monospaced ASCII text.]

A possible hazard If they are not "with" each other, is that they may not dovetail in" with each other, may contain errors, or contrary info (w/r/tt design. params, I/Os, scope, or practical use. 
Another may be that people often go to one when the other is unavailable, and so, may not get a more complete/robust picture.
[Examples: the company power goes out so all online doc is "poof"; the only way to avoid the person staring at the side of your head in the bus is to bury it in a manual so your boss will raise that annual review rating. Also, it makes you look insane so no-one will mess with you, except for another engineer noticing you are reading a Tektronix STI, Euclid/Tunis, or PL/1 manual drawing further stares pondering whether there's a Zippy or Dilbert book hidden from view.]

Are the build-test-release cycle processes (and criteria for their "acceptance" testing suites and pass/fail states) documented somewhere?
As former test/qa engineer, I find it very reassuring and useful to tap into historical snapshots of past and present builds/releases, esp. during Alpha and Beta reviews of whatever section I volunteer to verify and attempt to break (with white and black box testing, limit testing, load testing, la te dah).

It often also helps me to clarify my questions so they are based more "in sense" and to find the right person working on and/or very knowledgable about a module or code segment.
Your description is concise and useful; I appreciate your quick and accomodating assistance!

best wishes,
chris


More information about the freebsd-questions mailing list