Re: [gentoo-dev] Guidelines for IUSE defaults

[james]

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