On Thu, 2016-01-28 at 19:23 -0700, Chris Murphy wrote: > On Thu, Jan 28, 2016 at 6:01 PM, Adam Williamson > <adamwill@xxxxxxxxxxxxxxxxx> wrote: > > On Thu, 2016-01-28 at 17:43 -0700, Chris Murphy wrote: > > > On Thu, Jan 28, 2016 at 1:01 PM, Adam Williamson > > > <adamwill@xxxxxxxxxxxxxxxxx> wrote: > > > > > > > 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 > > > > > > How about option 1. That leaves x86_64 and ARM only; and then where > > > appropriate the distinction between BIOS and UEFI. > > > > > > Next, duplicate that page, deleting ARM and UEFI, and changing x86_64 > > > and BIOS to i686. i.e., a 32-bit x86 only specific page. > > > > > > At least it's available. And it might give us some gauge of > > > interest/activity in testing 32-bit? > > > > Well, it's possible. Speaking selfishly (as the one who's likely going > > to wind up doing it), it involves a bit more work than the other > > options. It would be included in the 'Summary' pages, I don't know if > > that's a good or a bad thing. > > Yeah I forget that this isn't just a single static page, but there's > more going on with it. To give the quick version of the implementation details, it's not a *huge* problem - the way python-wikitcms works, when you create validation event, you more or less automatically get result pages for every matrix template that exists. So adding a new page is really just a case of adding a new matrix template page, and then everything else sort of magically happens. It's been like a year or two since I set this stuff up so there may be some little details I forget, but that's the big picture. So it's not a big issue, if we really think it's the best approach. Now I refresh my memory on the details of how the Summary page is generated it wouldn't be a huge problem to leave a page out of the summary if we wanted to, even. So it's all possible. > OK so how about doing 1 and then punt? i.e. > just wait to see who shows up for the testing party, and then decide > exactly what this i686 variant page would look like? Maybe it's a > mirror in functionality to the main one; or maybe it can just be a > static checklist? The only issue with this, I'd say, is that of course the material we have available affects the testing that gets done. If someone's *really* motivated to do i686 testing they'll do it anyway. If they don't care at all they won't. But if they're somewhere in the middle, maybe they'll do it if the empty spaces are right there in front of them, but not if they aren't... Since I've built the whole whizzy clanking Wikitcms setup anyway, we may as well use it. So if we're gonna keep i686 testing, I'd prefer to do it in such a way that it works within the Wikitcms stuff. It's no harder than setting up a 'static checklist' page anyway, really, now I put my mind to remembering the details. > There are quite a few things in the matrix that are considered > "likely" working for one arch if it works on the other. Whoever's > testing may end up wanting to chop up that page into something smaller > anyway, depending on their resources. If that's plausible, all the > more reason for you to not spend a lot of time on this until there's > less uncertainty. There's a good chance it'll mostly be tested in VMs > running on 64-bit hardware. One situation I can kinda see is if we (Fedora as a whole) really make it *look* like we're completely going away from i686 with F24 - then see how hard the pushback is. As you said, if people *really* care, probably the way to move forward is some kind of 'i686 SIG' or whatever. If there's a group of people really dedicated to maintaining and testing i686, then it gives us a clear way to move forward: we talk to them about what would help them do the testing, and we provide it - much as we provide the matrices and the release blocker process and whatnot for Server and Cloud, but they clearly have or share responsibility for doing the actual *testing*. If it turns out there are people who complain but no-one who actually steps up and says "yes, we are willing to test i686 and fix the bugs that show up", then we just leave it all gone. So, that's kind of a scenario for the 'do 1) and punt' idea, I guess. -- 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
