On 02/03/2017 12:39 PM, james wrote:
So imagine flags are a giant 'sparse matrix' that I need to 'mollify'
individually periodically, then run CI on that complete-set of packages,
and then test against automated attack vectors.
So, were we to want to 'enhance' flag representation from a binary
tree form to a sparse matrix, there are many more robust things
we can do. For those not aware of sparse matrix benefits, they
basically provide for streamlined solving of large complex problems,
buy using special (matrix tricks) mathematical techniques to reduce
the full, valid set of parameters, into very small sets of smaller
problems. IMO, very applicable to CI and flag set testing. These sorts
of theories are trivial to test on minimized systems (huge shout out to
Walt, as the king of the minimizers!).
For starters, I suggest the package listing (i.e.) the future complete
listing of gentoo packages down the 'Y' (left) axis and the actual flag
status along the (top) X axis. Left Margin and Top margin
representations allow the (sub)matrix to be manually viewed as a typical
2-D table, very convenient. First we can alphabetize this 2-D flag
matrix for a baseline (base profile) reference matrix.
But, once you start thinking about it, recalling your grammar school
matrix algebra class, you realized that grouping flags by their myriad
of heuristical properties, you realize that the aggregate effect of a
flag is not binary at all, but more akin to a 'fuzzy logic' function.
For example, cluster up a group of packagers inside the sparse matrix
that all have the same flag, but it has different meanings, slightly per
package. Turn that flag (on) for all packages and it has a "staccato"
effect on the system as a whole. Turn that flag off and it is
null-effect (at least theoretically). This is how we currently discern
flag setting meanings, but by manually bumbling around in the dark.
Now, any number of flag activation, per package of that flag may or may
not have secondary (tertiary etc; kinda line harmonics on a LaPlace
or Z/s transform) effects on the system as a whole. WE as a community,
have been ad-hoc tweaking flags and noting the effects, in an
inconsistent manner, with only anecdotal means to share the result
of those intrinsic flag settings. Alchemy 2,000 years ago was almost
identical to how we (today) analyze flag effects. Grouping all the
packages with a given flag, for CI studies allow for row reduction in
the sparse matrix of flags, as CI runs are amassed into a larger
collective of heuristical interpretations of such specific flag groupings.
Or that is my latest treaty_proposal, on how to filter a particular
collection of flag settings and installed packages. I am open to other
ideas too, as well as traditional regression testing in a hybrid model.
Ultimate flexibility in the profile/flag tree, greatly simplifies the
automation of CI testing and automated results interpretations, imo. So
hopefully I have sufficiently explained my pathway forward, what I need,
and how these seemingly disparate issues, are all really just moving
parts of a much larger (system) need.
At the very least a 100% flexible flag settings/negation, via a profile
tree and other mechanisms, will not hinder the formation of matrix
representations of flag configuration sets, which are keenly needed to
draw reasonable automated conclusions from CI, at least related to flag
settings and secondary (inter-intra) flag setting interactions.
hth,
James
