| 1 |
On Wed, 2007-05-02 at 01:32 +0200, Marius Mauch wrote: |
| 2 |
|
| 3 |
> |
| 4 |
> I'd approach it a bit different: Before creating fixed classification |
| 5 |
> groups I'd first identify the attributes of tests that should be used |
| 6 |
> for those classifications. |
| 7 |
> a) cost (in terms of runtime, resource usage, additional deps) |
| 8 |
> b) effectiveness (does a failing/working test mean the package is |
| 9 |
> broken/working?) |
| 10 |
> c) importance (is there a realistic chance for the test to be useful?) |
| 11 |
> d) correctness (does the test match the implementation? overlaps a bit |
| 12 |
> with effectiveness) |
| 13 |
> e) others? |
| 14 |
|
| 15 |
There is one serious problem with this: Who's going to do the work to |
| 16 |
figure all this out for the 11,000 odd packages in the tree? This seems |
| 17 |
like a *huge* amount of work, work that I have no plan on doing for the |
| 18 |
100-odd packages I (help) maintain, let alone the 4-10 different |
| 19 |
versions of each package. I highly doubt other maintainers want to do |
| 20 |
this kind of work either. |
| 21 |
|
| 22 |
Daniel |
| 23 |
|
| 24 |
-- |
| 25 |
gentoo-dev@g.o mailing list |
Archives