On 02/09/2010 08:57 AM, Thomas Bächler wrote:
Am 09.02.2010 14:34, schrieb Dan McGee:
Most importantly, the signoffs are there to verify that neither the package files nor the contained binaries are corrupted. An i686 signoff is still necessary to see that the package installs fine and the binaries actually execute - an x86_64 signoff will tell you that the commands in the PKGBUILD are sane, but not that nothing got corrupted.
Remember that one of the original reasons we went to a "draconian" signoff policy was due to an unbootable kernel getting into [core].
I remember the discussion. The problem was that the i686 package got corrupted during upload.
We haven't had that happen again so something worked here. When you look at it that way, a signoff from another person is essential to prove that it didn't break badly. No noise for a week however does make it pretty likely that nothing broke.
... or that nobody tried it (as probably nobody tried testing/openvpn, one of the core packages that barely any developer uses).
I like a way I've seen Aaron do this-- when signoffs are not forthcoming on something, it's okay to have someone signoff as "responsible" in such a scenario, without actually testing. It's an "I take responsibility", which certainly it isn't the same as a test, but is at least a somewhat higher bar in practice, since nobody wants their name explicitly associated with broken stuff. - P