build+install tools... exist or under development?

C Gray frankfenderbender at council124.org
Tue Feb 13 05:58:04 UTC 2018


So, to attempt to actualize some changes which may proactively make pre-installs, installs, post-installs, and all of the ensuing troubleshooting easier, I have a few questions first, which may help me to better understand the current status, and projects, designed to improve areas on this dynamic FreeBSD project:

01) Is there a BOM (list of all folders, files, links, partitions, BIOS changes, etc. required before and made during a Base install?
02) Is there a post-install BOM-checker toolset (which report after and maybe even can stop "live" installs when a dependency install fails, required file is an incorrect version, or an incompatible part is found?
03) Is there an install-expected links list checker? [example /use/local/lib symlinked to a lib in /lib?
04) Is there a setting that will avoid all of the non-Base "choices" regarding paths to installation problems as with the optional install menus?
05) Is there a checker and reporter for general categories of installs (python dev, 64-bit only) which will filter out beforehand all of the choices which are pre-checked or which could inadvertently get checked or unchecked with binary either-or checks... so that install failures and missing dependency errors are reduced to as close to zero as possible?
06) Is there a process whereby "fixes" are fully tested so they do not break working or previously-fixed code?
07) Within what process and parameters/criteria of "acceptance" does one add or modify a release branch?
08) What test suites exist and do code changes on all branches require running them on non-merged copies before adding them?
09) Do 'change request' processes exist?
10) Does a BOM-like tool list all function and modules, along with their scope, the global vars they depend upon, whether they parse a parameter list from left-to-right or right-to-left, modules in the Base or in other ports which they expect to be set before installation, etc.?
11) Are tools like Purify (Rational created; IBM bought Rational) used to find dead code w/i live code before a release?
12) Are tools like PureCoverage used to see if all code is actually being tested by regression, acceptance, and release test suites?
13) Is there a list of severity-rated, priority-rated, and platform-segmented issues so that it can be assessed which systems at any release point are the least and the most prone to issues?
14) RCS vs. SCCS vs. CVS vs. ClearCase (Mentor Graphics breakaway bought by Rational bought by IBM) vs. SubVersion? What development use, selected tool, and experiences with it?
15) Of the window/display managers, which has worked and which have failed for you w/r/t kde, lumina, and gnome on TrueOS server?
16) Has anyone gotten kdevelop to work on TrueOS server?

Okay, that's it for now. Hope to hear from that grey matter out there over time on any of the above....

Has anyone installed TrueOS w/o an issue rearing its head, and if so, did you avoid all followup "check-marked" installs, staying as close to a Base install (which is really never defined very well anywhere, OR, there wouldn't be checkmarks , just an install).
It seems that verification/validations of categories and platforms of installs could be more robust... more complete, better tracked in terms of successes and problems between releases and in the installer itself.

I imagine that everyone has some answers to some of these questions. I know everyone is busy so I will appreciate any answers whenever you have time, so take your time. 

Is it w/i the realm of usefulness to present verified installer configs for each set of platform install-type (other than base) combinations which can be called up as a pre-install menu? 

One size does NOT fit all. And, there is nothing "free" about everyone spending their free time debugging install issues... much like reinventing the wheel over and over, or having millions of people write work-around code for the periods where Microsoft IE, C, universal calendar start-times, etc. do not follow standards. Borland and Unix clock seconds started in 1971 and sloths started in 1900 so that dual compiler projects would collide wherever time was an essential. Anyway, issues others have solved on other projects are very useful in preventing like types and dead time required to find and work-around them... by proactively avoiding them altogether. I'm preaching to the choir, but I am also interested in finding out the secret handshake, and this seems a way of hearing truth in both unique and common-but-silent good/bad experiences.

Where are the development, defect, enhancement issue lists, and, do you know of contacts for addressing any aforementioned tools or issues, and if so, how do I contact them to assist?

thanks,
chris
frankfenderbender at council124.org






More information about the freebsd-questions mailing list