From owner-freebsd-questions@freebsd.org Fri Feb 16 04:31:22 2018 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C649BF12B6B for ; Fri, 16 Feb 2018 04:31:22 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mout.kundenserver.de (mout.kundenserver.de [217.72.192.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.kundenserver.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 38A19835E2 for ; Fri, 16 Feb 2018 04:31:21 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from r56.edvax.de ([92.195.213.55]) by mrelayeu.kundenserver.de (mreue105 [212.227.15.183]) with ESMTPA (Nemesis) id 0MasOo-1f5iLE2Vis-00KQ7i; Fri, 16 Feb 2018 05:25:58 +0100 Date: Fri, 16 Feb 2018 05:25:57 +0100 From: Polytropon To: C Gray 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> Reply-To: Polytropon Organization: EDVAX X-Mailer: Sylpheed 3.1.1 (GTK+ 2.24.5; i386-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:JFUZgdIlpJIjIlj7NsWuznhOmB6HQ3BFRScFpULBZi3CgkzF85C 5uDOKi5hN3QRmqDJCQf29vXq1sRdPkL32vjG/xsaVyAv+SZCLpufNvKB38uS7G2IzYcnuLo 7YGd00x1Y5VFwcExvWipVPv0aPZRmZnf8u/1kgjwR4DuB2FI38eJ4TKf+Z6k6NMIvfTOtS8 xVxiRDI9tkzucL0PqDSbw== X-UI-Out-Filterresults: notjunk:1;V01:K0:QqNz4CdeXeo=:5+dqJU2FWDYshonbhGux3u +pfBhykXnqh1lddulqkwA1A9G9ChwUgZTeLKxOfhF2/6Fm/YWWxLK7uWSPLkpwHn5q/eCotDG wZdalT/6IG92QFYefB0msu790UL3WYID0rTQhEp0mrrmQD3S/B+3m87y6Ge5ExC/SGDxx3d1K Ihb+RVR+lkZGPmNNQOTjb5R6b14WRGzsL1gznZYR+pTgeicKDI9oo2pu9JbILdzX31b2sXFJF Mc1xdikDa5A08Bu6Jlx75vCl64+WBosi7jvW0eqClyfW4IJhWpsAYNrtp6BZ2PaKiSjdLhRCL gqFvTFcr2gfmkyk5Yt9QteOmRGv9HUWXrt/I+aFwYOEVPZMAqt2q1My2p2heCvcvGJfAmkwrN gUuG8AK1L6DxHUlGqda8dUlkQ5gY11GSGBmdje7Ef5LjBDB70k5PG5y45Gh0Opi7Mcnx8oSge ATAzDAp01BHN4RRFeMkfwXlHcLN+kTVDuCro/YGuWnx++MIa9VyTnl4/wbFe4QFkNQGv3V+fS lZmgRtEAK5Z6aH9YONcYwwHj00QU30sayOEJpsfq5hLaFwrpOHcdWteo0OJY0xDqVMB3d6DYE TWvKHdwetc2xoWI3l56D7bal1AG+z3+1y9W5u5FEmbMOwQzPhUjIM4J65ziLLyl4U9eBxP4B5 qud8gpxHcoobDm04MV84UuH96pbZ23MDGF3czzE/S8m4IsoGj6koWT1Shkd5bWxe8cBmVksFf 25Wp1T0oCp5dNAqx/4CjBOfZlEQS4N5uP9BSeIj+RdRQdYiq+n/Ced4cNjw= X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2018 04:31:23 -0000 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, ...