| 1 |
I think that one of the crucial strengths of Gentoo is its ability to |
| 2 |
quickly incorporate and disseminate information, both new software and |
| 3 |
information about how well things work in a particular environment. |
| 4 |
|
| 5 |
If the notions of ARCH, OS, LIBC, KERNEL were truly orthogonal, this |
| 6 |
GLEP would make sense to me. In other words, if one could say with |
| 7 |
certainty that "ppc is ok", or "won't work with glibc", without |
| 8 |
needing to look at the other variables at all, then this would be |
| 9 |
fine, but I don't think that accurately represents reality. |
| 10 |
|
| 11 |
Leaving aside for the moment the question of who does QA and when and |
| 12 |
in what capacity, I think that the main purpose of KEYWORDS is to |
| 13 |
convey QA information. I will oversimplify at this point and roughly |
| 14 |
map arch to green, ~arch to yellow and -arch to red. This is the |
| 15 |
information users want and we want to convey: here's the tinderbox |
| 16 |
color of the package you're interested in as it applies to your |
| 17 |
machine. |
| 18 |
|
| 19 |
I think it would give much more flexibility and power to the QA |
| 20 |
process if this information was maintained completely separately from |
| 21 |
within ebuilds themselves. It would be a big matrix, currently |
| 22 |
5-dimensional: arch/os/libc/kernel/ebuild-version = color. |
| 23 |
|
| 24 |
This way, QA testers can convey the information about how the software |
| 25 |
behaves on exactly the systems they have, without necessarily having |
| 26 |
to meet the burden of collecting enough data about how it behaves on |
| 27 |
platforms they may have no access to. Others can do that at a later |
| 28 |
time, and we do not waste the timely information that we *do* have. |
| 29 |
|
| 30 |
I suggest that it would be neither practical nor particularly useful |
| 31 |
to have users directly accessing the master matrix, which would |
| 32 |
probably reside in a relational database. Instead, there would be |
| 33 |
some process that could be adjusted based on demand for various slices |
| 34 |
of the matrix that rips static dictionaries of it, perhaps in dbm |
| 35 |
format. ebuild-version => color. Portage should have no greater |
| 36 |
burden at emerge time than it does now, and it may in fact be somewhat |
| 37 |
less, I'm not sure. |
| 38 |
|
| 39 |
The matrix slice could be retrieved at emerge sync time, either as |
| 40 |
part of the normal rsync process or via a separate http fetch. |
| 41 |
|
| 42 |
|
| 43 |
-- |
| 44 |
gentoo-dev@g.o mailing list |
Archives