llvm dev - Jan 2013 - [LLVMdev] Obsolete PTX is NOT completely removed in 3.2 release

Pawel,
	You don't know me but I'm one of the release engineers for
BIND 9 and BIND 8 before that.  I have been doing release engineering
for about 1.5 decades now.  One of the things you DO NOT do is
replace a tarball.  Machines get compromised.  Good distributions
get replaced with tainted versions.  One of the few ways the rest
of the world has some assurance that they are getting a untainted
version is that what you get now is what you got when the product
was first released.  One of the way a site learns that it has been
compromised is tarballs changing.

Yes, the replaced tarball is signed with your signature but I don't
know you from a bar of soap.  I don't know what your relationship
is to UIUC.  There is NO information that I can see on the llvm.org
web site that says that you are permitted to sign the distribution.

What I do know is that the release announcement came out on the
20th of December and the tarball was replaced on the 12 of January
and there has been nothing sent to the llvm announce list.

This makes me uneasy.

gpg -v /usr/ports/distfiles/llvm-3.2.src.tar.gz.sig
gpg: assuming signed data in `/usr/ports/distfiles/llvm-3.2.src.tar.gz'
gpg: Signature made Sat 12 Jan 02:30:04 2013 EST using DSA key ID 7CB2EFFB
gpg: using PGP trust model
gpg: Good signature from "Pawel Wodnicki (elektrknight) <root at
32bitmicro.com>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 4D8F 3DD4 7CBD 5212 7155  AC65 09C4 E700 7CB2 EFFB
gpg: binary signature, digest algorithm SHA1

As for downstreams being involved in the release process, they are. There
is a implicit step that you should write down in your formal processes.

	    Do NOT change a released tarball for any reason.

We have re-released tarballs over my and other developers objections.
Everytime this has been do we have been 'tared and feathered' and
quite rightly so.  Unfortunately each new manager needs to learn
this lesson.

Yes it would be nice to get feedback that something broke on some
platform before you cut the final release.  I understand that
feeling.  I don't know how many times I've cut a release to only
find that BIND doesn't build in a particular build environment
despite using build farm and doing release candidates.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE:	+61 2 9871 4742		         INTERNET: marka at isc.org