Date: Fri, 16 Feb 2018 05:25:57 +0100 From: Polytropon <freebsd@edvax.de> To: C Gray <frankfenderbender@council124.org> Cc: freebsd-questions@freebsd.org Subject: Re: any problem going from 9.x (don't laugh) to 11 directly? Message-ID: <20180216052557.5d6cbfcb.freebsd@edvax.de> In-Reply-To: <02A77ACD-1796-44A8-A1F4-43B4FEB56A80@council124.org> References: <20180215011907.6620E1B2DE28@ary.qy> <868tbvhwix.fsf@red.stonehenge.com> <7795e899-160e-f6af-c02d-6fa44982f864@ShaneWare.Biz> <8212BAA6-DC01-4AD5-BCBF-012D97447060@council124.org> <20180215090704.c1f4dd98.freebsd@edvax.de> <02A77ACD-1796-44A8-A1F4-43B4FEB56A80@council124.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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". :-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180216052557.5d6cbfcb.freebsd>