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