* Justin Erenkrantz <justin@erenkrantz.com> [2006-04-07 20:42:48]:
> I've seen you raise this point before, but I believe this is a
> misunderstanding of our intended release processes. I don't believe
> we should need three sigs on *each* file to release that file - we
> should need at least three sigs *in total* to release.
For as long as I've been the release manager, I've never seen anyone
advocate anything other than 3 signatures per file (with the provision
that .tar.gz and .tar.bz2 can be both signed after testing one and
comparing contents).
I believe that only 3 sigs per release is too low to hope to catch any
problems during the blessing phase. Sure, it would make the release
process faster, but having 2 unix sigs and one win32 sig does not
convince me that the packages are ready for release. What if the
win32 signer doesn't notice a problem because he doesn't do a full
6-way test (such is not required by our current policies, a single RA
method and a single backend is sufficient), which makes us release a
win32 package that has a severe bug elsewhere, in an untested region
of the code?
Furthermore, the RM's signature is not, in itself, blessing. It is
originally there so that other committers can verify that they are
testing tarball that wasn't tampered with since the RM uploaded
it. If it were any other way, I could not provide a signature for the
.zip, because I have no working win32 environment to run the tests
in. Granted, I associate my RM signature with a test run of the unix
tarball, but the primary intent of the RM sig is not to bless the
release, but to bless the release to bless, as it were.
> (The assumption is that the RM has signed all of the files as he
> created them.) Having as many sigs as possible is goodness, but we
> shouldn't need every file signed 3 times to issue a release. That's
> way overkill. -- justin
I find 3 to be most acceptable, and that the signature process is
quite speedy when there is a single flavor of Subversion to sign.
In short, I don't believe that compensating a larger number of
packages by lowering our standards is an acceptable option.
- Dave.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Apr 8 14:07:45 2006