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

Polytropon freebsd at
Fri Feb 16 04:31:23 UTC 2018

On Thu, 15 Feb 2018 11:06:22 -0800, C Gray wrote:
> 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.

That is correct. Even when your tools are working 100 % as intended,
problems with the procedures (simplified: "how to properly use the
tools") can lead to crappy software. Reality does show us this fact
every day. :-)

> [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.]

There is absolutely no problem "transpiling" the manpages into HTML
or PDF as formatted documents - and vice versa. As everything will
basically be ASCII text with "formatting macros", such tasks could
be automated.

> 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.

That is the kind of documentation you typically find for "Windows"
(_if_ you find public information at all). Sadly, the "RAD mentality"
on Linux often leads to similar problems where there either is no
documentation, or it is misleading, outdated, or incomplete. I know
keeping documentation "in sync" with the software it belongs to is
a hard task, but it is a task of _great_ value. Every programmer or
system administrator will confirm this, but it's also important for
testers so they can verify that what they see is what they are
definitely expected to see.

> 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.]

Today's documentation is often found in Wikis (internal) or put
into private users' blogs and web pages. It's scattered across
the web and fills the search engine result lists, even though
it's not what you're looking for. The search engine usually has
the concept of presenting results, no matter if they even apply.

Oh, and regarding bosses and manuals: "You are not expected to
know this. That's why I've locked the manuals. Call the service
representative or a consultant if you have problems." ;-)

> Are the build-test-release cycle processes (and criteria for
> their "acceptance" testing suites and pass/fail states)
> documented somewhere?

I'm quite confident they are. You should probably ask the FreeBSD
team which is responsible for running the build systems, they
will know the exact answer and can probably point you to where
those procedures can be found.

> 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.

Note that the build infrastructure is not only for the OS (kernel
and userland), but also for the ports submitted by external
maintainers. As a programmer, it's very helpful to know what to
expect from the system your software will be built on; knowing
the procedures for the processes involved here can help to write
better code (so there will be fewer patches and workarounds
neccessary to "fix the code until the compiler doesn't complain
anymore". :-)

Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...

More information about the freebsd-questions mailing list