On Fri, 2013-06-28 at 17:00 +0100, Matthew Garrett wrote: > On Thu, Jun 27, 2013 at 07:34:06PM -0400, Jaroslav Reznik wrote: > > At the Fedora 19 Final Go/No-Go Meeting that just occurred, it was > > agreed to Go with the Fedora 19 by Fedora QA, development, release > > engineering and FPM. > > 979205 got filed yesterday, which makes it incredibly difficult to > install F19 on Macs while keeping OS X. This is rather frustrating, > since Fedora's the only distribution with any significant support for > running on Apple hardware. There's two problems here: > > 1) QA apparently don't have any Macs, so it's difficult to test this > case > 2) Policy says that once the go decision has been made, there's no way > to revoke it > > (1) is something that we really need to solve, because it's clearly > unreasonable to expect community members to have a test Mac to install > every RC. So turns out I was wrong on that: "we", (by which I think you mean "paid Red Hat QA staff" - we certainly have regular testers with Macs, Chris is one of them) do have a UEFI Mac Mini in Brno, we arranged that last year. What we don't have is a test case for Mac dual-boot. This is because it hasn't really been considered to be a release requirement (ever, this release is no different from any previous one). We have a dual-boot with Windows test and explicit criterion: "The installer must be able to install into free space alongside an existing clean single-partition Windows installation and either install a bootloader which can boot into the Windows installation, or leave the Windows bootloader untouched and working" https://fedoraproject.org/wiki/QA:Testcase_dualboot_with_windows But we do not have anything corresponding for Macs. This was a conscious decision made in the past, not an omission. If we now think it is realistic and worthwhile to support dual boot on Macs we can re-consider that decision, but it would be an explicit policy change, not just rectifying an oversight or something. (I'll note that, quite honestly, I wouldn't consider UEFI dual/multi boot of any kind remotely robust as things stand. It still appears to be very much a work in progress. The only thing that we really have code for that I'd vaguely stand behind is Windows BIOS dual boot.) > (2) is stranger. Obviously once an image is released, we're not going to > be able to recall it, and we have no history of producing updated > install images. But right now we're in a window where we haven't > officially shipped anything and are saying we can't fix this issue > purely because we've written a policy that says we can't. Well, the policy was presumably not yanked out of thin air. It predates my arrival at RH/Fedora, so I don't know personally the reasoning behind it, but I can guess that a lot of it has to do with release engineering and website logistics. We need to have a definite point of no return in order to do a final stable push, mash, unfreeze the updates repo and stage everything out to mirrors. That's not an overnight operation. I'm not releng so I don't know for sure, but it may well be that at this stage in the game it isn't actually straightforward/possible to 'un-Gold'. > There are workarounds - users can either perform custom partitioning, > wipe their disk entirely or install using beta and then upgrade to > final. It's not an utter disaster. However, if it had been caught 12 > hours earlier, we'd probably have been willing to delay the release to > fix it. I'm not actually sure that's the case. As I said above, we don't have a release requirement for this and that is at least in part an explicit choice, not an oversight. We explicitly did not consider Mac dual boot a case we wanted to commit to 'supporting' in the past. I'll also note that we haven't _definitely_ confirmed the issue as described yet. Chris is a good tester, but single testers can always get things wrong. I would like it if someone else with a Mac can return it as close to a stock factory configuration as possible and try a Fedora 19 install on the simplest possible path and confirm that they hit the bug. There is another 'workaround' you haven't considered: we can simply build an updates.img that fixes the issue (or works around it, by ditching the commit from 19.13.10 that apparently broke this case), and link to that from the common bugs page and the bug itself. > I don't know that there's a good answer here. It's unfortunate to ship > with somewhat broken support for a widespread class of hardware, > especially when Fedora's compatibility with that hardware is a unique > selling point. Well, I'd say _limited_ compatibility. We've had all kinds of bugs in Mac support in, well, pretty much all previous releases too. It's not as if we have a track record of excellent support, we have a track record of 'you can probably kind of make it work if you try hard enough'. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
