On 12/03/2016 09:33 AM, Michael Orlitzky wrote:
On 12/03/2016 09:25 AM, William L. Thomson Jr. wrote:
This is generally considered infeasible:
I would not think such, just need a wrapper to run around each package that
would get its USE flags and re-emerge it a few times.
If a package has 10 USE flags, and if each can be set on/off with no
constraints, then that gives you 2^10 different ways to emerge it.
Perhaps the default (or a minimal) set of flags chosen by the ebuild
maintainer, appropriate project or QA (as a last result) could be tested
on an official gentoo tinderbox/CI cluster.
Then a stage-4 image could be made available so anyone can install
gentoo cluster nodes quickly and a bit of ansible code to load the
framework onto a openstack-gentoo-cluster, for example. This would
streamline the task-set for others to self-test any ebuild with a
unique set of flags and then upload those results or make those results
available via an overlay or github mechanism.
If you automate it for a few gentoo devs, putting out a stage (4)
for specific hardware (like amd-64) would pretty much make it so
hundreds or thousands of tinder-CI gentoo-centric efforts could exist
for the users and proxy folks.
Once folks see that "power" of a gentoo cluster, then they'll likely
use gentoo-clusters for a myriad of needs. That will motivate them to
take a 'deeper-dive' into gentoo internals, culminating in many more
gentoo devs, thus growing the technical talent base of gentoo.
hth,
James
