Fedora 19 status is ALIVE, GA on July 02, 2013

[Adam Williamson]

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