| 1 |
>>> Anecdotal evidence against, currently gnupg 2.1.21 scdaemon bug will |
| 2 |
>>> happily sign a third party public keyblock's UID using signature subkey |
| 3 |
>>> on smartcard, which results in useless signature that doesn't have any |
| 4 |
>>> effect, but the application builds fine. |
| 5 |
>>> |
| 6 |
>>> This means gnupg 2.1.21 is not a candidate for stabilization, but it |
| 7 |
>>> certainly builds fine. |
| 8 |
>>> |
| 9 |
>> |
| 10 |
>> Stop trolling - you know perfectly well that this sort of issue would |
| 11 |
>> never ever be caught during arch testing. Nor should it be - it's called |
| 12 |
>> *arch* testing for a reason. |
| 13 |
|
| 14 |
Question is what's more a problem: Having an outdated stable package |
| 15 |
because nobody cared about stabilizing a new version (in most cases this |
| 16 |
will end with a rushed stabilization once a security bug was fixed in |
| 17 |
the package) or move a package in time from ~ARCH to ARCH and deal with |
| 18 |
the fallout sometimes. |
| 19 |
|
| 20 |
Having a real AT doing real arch testing work would be ideal. But face |
| 21 |
it: We don't have the required man power. Let's try Debian's testing |
| 22 |
approach and move packages to ARCH in time and don't wait for some |
| 23 |
magical appearing bug reports because someone really tested a package in |
| 24 |
~ARCH. Severe problems will be reported anyways... |
| 25 |
|
| 26 |
|
| 27 |
-- |
| 28 |
Regards, |
| 29 |
Thomas |
Archives