| 1 |
Christian Faulhammer <opfer@g.o> posted |
| 2 |
20080905214759.71ca271c@×××××.solaris, excerpted below, on Fri, 05 Sep |
| 3 |
2008 21:47:59 +0200: |
| 4 |
|
| 5 |
>> 2) Should I file stabilization requests on software that works mostly |
| 6 |
>> as in everything that I use it for normally but I can force it to fail |
| 7 |
>> if I feed it some really strange input or contrive a specific set of |
| 8 |
>> options that will cause invalid or incorrect output. |
| 9 |
> |
| 10 |
> Try to sort it out with upstream (original package author). Depends |
| 11 |
> on the problem, if an older stable version shows the same behavior it |
| 12 |
> should be no show-stopper. |
| 13 |
|
| 14 |
Also, consider merging with FEATURES=test and the test USE flag if |
| 15 |
appropriate as well. If a package fails its tests and doesn't have |
| 16 |
RESTRICT=test turned on in the ebuild, and if the previous version passed |
| 17 |
the tests, it's not likely to be stabilized. If the previous version |
| 18 |
failed the tests as well, for everyone, then in theory, RESTRICT=test |
| 19 |
should be on, and the fact that it isn't indicates a problem with your |
| 20 |
specific installation (either of that package or something else). |
| 21 |
However, theory doesn't always match reality as I'm sure you've observed |
| 22 |
by now. In any case, it's certainly worth checking for stabilization |
| 23 |
bugs for previous versions and seeing what the comments on testing were |
| 24 |
for them, then either exploring the problem locally or filing a bug as |
| 25 |
appropriate. |
| 26 |
|
| 27 |
-- |
| 28 |
Duncan - List replies preferred. No HTML msgs. |
| 29 |
"Every nonfree program has a lord, a master -- |
| 30 |
and if you use the program, he is your master." Richard Stallman |
Archives