On 10/02/10 00:34, Paul Mattal wrote:
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.
Well...
allanbrokeit
