Date: Thu, 15 Feb 2018 11:06:22 -0800 From: C Gray <frankfenderbender@council124.org> To: freebsd-questions@freebsd.org Subject: Re: any problem going from 9.x (don't laugh) to 11 directly? Message-ID: <02A77ACD-1796-44A8-A1F4-43B4FEB56A80@council124.org> In-Reply-To: <20180215090704.c1f4dd98.freebsd@edvax.de> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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.=20 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=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?02A77ACD-1796-44A8-A1F4-43B4FEB56A80>