Description of problem:
Fedora-16-Alpha-i686-Live-CHECKSUM 31-Aug-2011 12:12 414
Fedora-16-Beta-TC-i686-Live-Desktop.iso 31-Aug-2011 02:36 593M
Fedora-16-Beta-TC-i686-Live-KDE.iso 31-Aug-2011 02:37 665M
Fedora-16-Beta-TC-i686-Live-LXDE.iso 31-Aug-2011 02:39 527M
Fedora-16-Beta-TC-i686-Live-XFCE.iso 31-Aug-2011 02:44 613M
The ISO images have Beta in their name, but the CHECKSUM image has Alpha in its name (but its contents is OK).
Version-Release number of selected component (if applicable):
Fedora 16 Beta TC1
I didn't find any blocker criteria, but still proposing as Beta blocker. The checksum files should always be correct.
Only now I spotted another problem - the ISO images shouldn't have "TC" in their name, should they?
Actually, I believe the live checksums are generated manually, not by pungi.
Live images are checksummed by hand I believe. Re-assigning to releng for Fedora.
Discussed at 2011-09-02 blocker review meeting. All agreed this should be a blocker issue as it impedes automated checking, but there is currently no release criterion for checksums (or various other 'obvious' things about file names, what files should be present and so on). Accepted provisionally as a blocker, I will propose release criteria in this area.
I should point out here that QA currently has no access to the signed checksum files which are produced after the Go/No Go decision, and it's possible though unlikely that the name could change even after verifying that the unsigned checksum name is correct. There is also currently to access to the .torrent files prior to publication, so no way to check the contents of those either (both names of files, and whether the checksum file is signed). See https://fedorahosted.org/fedora-qa/ticket/237 and https://fedorahosted.org/rel-eng/ticket/4906 .
Actually, from looking at the commands used for doing the signing at
the signed file is written to a different name and then moved to the same name as before, so the signed name is susceptible to mistakes. So it appears to me that verifying that the unsigned checksum file name is correct has limited value in ensuring that the signed checksum file name will be correct. The only way to do a proper test would be to at least have access to a list of file names including the signed file. And it would also be helpful to be able to verify that the checksums are the same as those in the unsigned file, meaning at least partial access to the contents of the signed file itself. And without access to the entire signed file, there's no way to verify the signature.
In any case, any mistakes in the checksum file used on the mirrors can be fixed afterwards. (In fact, the F15 checksum files were resigned shortly after the official release, so there are two signed versions - see http://robatino.fedorapeople.org/checksums/15-Final/ . The name didn't change, but the content did.) Mistakes in the .torrent files can't (or at least that's what people tell me every time I point out that the latest Alpha or Beta torrents have unsigned checksum files), so are much more serious. And QA currently can't prevent this since it has no access prior to public release.
The Live checksum file and ISO names are wrong again in 16 Beta TC2 (both contain "TC") but as pointed out above, the much bigger problem is the inability to correct certain content before public posting.
Why do you say the ISO name is wrong if it contains TC? Containing TC is correct: TC builds are not release candidates and should not be named as if they were releases. Only RC builds should be named as if they are releases.
That makes sense, but in the past, with a few random exceptions, all TCs and RCs for each milestone (Alpha, Beta, Final) were named exactly the same - you can see the names by browsing through http://robatino.fedorapeople.org/checksums/ . I don't know if there's an explicit policy regarding the names.
Also, the pungi-generated 16 Beta TC2 ISOs and checksum files are named in the usual way (without the "TC"), so if there is a policy, then one of them is wrong (either install images, or live images) assuming the names are supposed to be similar.
so the critical issue reported in this bug in TC1 - the checksum filename not matching the image filenames - is fixed in TC2, regardless of whether it's right for the names to have TC in them or not. the TC2 filenames match.
various other issues have been raised, but I think we should open new bugs for any specific concrete issues in TC2, I think this report would get a little confused if we let it continue to grow.
andre, please file new bugs for any specific TC2 concerns. releng, it might be good to have really consistent procedures for naming images and checksum files, and making sure they're correctly signed and torrented and so on.