Obsolete PTX is NOT completely removed in 3.2 release


  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.

Seems like a sad situation that will only get worse.

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.

This might be one of the lessons from this debacle that new
LLVMRM should somehow be brought into the "web of trust".

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.

Perhaps not, but it seems that in the age of social coding and
IRC one can misconstrue the allowance to make other changes to
changing the tarball. For that reason I agree, it should be
spelled out in bold letters at the end of the document, once
we are done *do not change the tarballs!*.

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.

Your situation is a bit different as you target a lot of
platforms out there. LLVM is released for a much smaller subset
so there should not be an issue to get the feedback.
And here I think lies a problem for any LLVMRM. It is an old
lesson re-learned yet again, do not try to wear too many hats
and get the community involved in the release.

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

Thank you for taking time to write this message, reading it helped
restore some sanity in a way that winking smileys didn't seem to.