| 1 |
Grant Goodyear wrote: |
| 2 |
|
| 3 |
>Alin Nastac wrote: [Wed Mar 09 2005, 04:57:15PM CST] |
| 4 |
> |
| 5 |
> |
| 6 |
>>Btw, what is the sense of ~arch if not "testing"? No gentooer |
| 7 |
>>expects from a ~arch ebuild to be stable, so the sky would not fall if |
| 8 |
>>you made a mistake and release it under this keyword. When I hear "I |
| 9 |
>>cannot mark foo library as ~arch because I don't know how to test it" |
| 10 |
>>smells like excuse to me. |
| 11 |
>> |
| 12 |
>> |
| 13 |
> |
| 14 |
>*Sigh* The meaning of ~arch is that, at a minimum, the package works |
| 15 |
>for the person who keyworded it (or, in some cases, worked for a trusted |
| 16 |
>user on whose behalf the package was keyworded). In other words, the |
| 17 |
>dev believes that the package works, and that belief is based on |
| 18 |
>evidence, not just wishful thinking. An "arch" keyword means that there |
| 19 |
>is considerable evidence that the package works for multiple people. |
| 20 |
>Packages that might work, but also might not, ideally should not be in |
| 21 |
>the tree at all, but could reasonably be package.mask'ed if testing is |
| 22 |
>imminent. |
| 23 |
> |
| 24 |
> |
| 25 |
> |
| 26 |
Not every time when I receive a new ebuild submittion, I also test that |
| 27 |
package because this is not always possible. Usually, I add the new |
| 28 |
ebuild with ~x86 and let testing to the user who request that. It may |
| 29 |
not be the orthodox way, but the risk of breaking something else in the |
| 30 |
process is 0 (a new ebuild means no other ebuilds depends on it). |
| 31 |
|
| 32 |
Users don't usually come to me and say "that ebuild works for me". I |
| 33 |
take silence as a sign that everything works. I am sure I'm not the only |
| 34 |
one doing that. |
| 35 |
|
| 36 |
I ask arches to mark a new ebuild as stable because a know bug have been |
| 37 |
solved or because the old stable version breaks something else. |
Archives