Hi, folks! As discussed at last week's meeting, it seemed a good idea to flag this up on the list for anyone who missed it. >From Fedora 24 onwards, FESCo has decided that i686 (32-bit x86) images are no longer 'release blocking', by policy: https://fedorahosted.org/fesco/ticket/1469 I have tweaked the release criteria 'preamble' text slightly to mention this explicitly, and also to link to the canonical list of release- blocking images that the program manager is maintaining now (the F24 list is https://fedoraproject.org/wiki/Fedora_Program_Management/ReleaseBlocking/Fedora24 ). I noted that the question of whether we 'support' / block on 32-bit *upgrades* is not yet resolved, so I've filed a FESCo ticket for that: https://fedorahosted.org/fesco/ticket/1539 What this means to us is pretty simple: we no longer have to worry about getting all the validation tests done for 32-bit images. Woot! We still *can* test them, if we want, but we don't have to. They're just like the LXDE live, or any other non-blocking image. An outstanding question is what we do with the validation matrices. Cloud was easy enough - I just marked all rows in the i386 table as 'Optional'. Base, Server and Desktop don't really split out x86_64 and i386/i686 (sidebar: the best thing about ditching i386/i686/x86_32 is we no longer have to be terminally confused about what it's freaking *called*...), so they're OK too. However, Installation is a bit of a problem: https://fedoraproject.org/wiki/Template:Installation_test_matrix quite a lot of the tables have 'i386' and 'x86_64' as environments. Especially with the Milestone column, listing i386 alongside x86_64 is a bit misleading if i386 is no longer blocking. I can see a few options: 1) just ditch the i386 columns entirely; openQA can continue testing it, and people can test manually if they want, but we don't bother tracking the results in the validation pages 2) stick an admon template at the top of the page saying 'the i386 tests aren't blocking', with links out to the criteria and/or the FESCo ticket 3) Duplicate each table which distinguishes between 'i386' and 'x86_64', so we have one table with just an 'i386' column and all tests marked Optional, and another table with the other columns and the appropriate milestone I can see arguments for any of those approaches. #1 is nice and simple and reduces the scariness of the page, but I guess means we don't get a quick overview of i386 status and probably means fewer people bothering to do i386 tests. I don't know how much we care about that. #2 is also simple and keeps the tests around, but people are probably going to miss the admon note and will therefore be confused about whether we're "missing" a lot of required results, if i386 isn't done. #3 is probably the most 'theoretically correct', but would probably be something of a giant PITA to read. I suppose we could have the i386 tables collapsed by default. That might work. Now I think about it, though, I think having rows that are identical except for their environments might confuse python-wikitcms, I'd have to look into it. If you're thinking "4) change the Milestone column", I'd rather not, because those values are somewhat significant to Wikitcms. Other ideas welcome! If anyone can think of any other system/process which might need adjusting for this change, too, please do let us know! Or just go fix it. ;) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@xxxxxxxxxxxxxxxxxxxxxxx
