----- Original Message -----
On 17 November 2016 at 10:22, Bastien Nocera
> ----- Original Message -----
>> No I am not asking for continuous testing. I am asking that if people
>> really care about the hardware support they get in the muck and do
>> just a little of the work in an organized fashion. Put together a Mac
>> SIG that focuses on getting the best experience on the hardware. Send
>> some QA people newer Macs. Otherwise how do people know that it is
>> really important to you versus "I have 4 minutes on the internet so I
>> can send a complaint email" important. Because at this point that is
>> all this looks like.
> So, I can't say that the problem is more systemic than what you describe
> without making it seem like I'm "sending a complaint email". Let me
> if you want a list of hardware enablement I've done on Macs over the years.
That was rude of me and I apologize. Dialing back my melodramatics.. I
will try to walk through my reasoning.
1. There was no proposal to drop Macs. Josh wasn't at the meeting but
said he would have argued for it at the meeting because he felt it was
too little too late. The other FESCO members seem to have disagreed
with him so it wouldn't have passed. If a proposal was made for it, it
would happen for Fedora 26 and not Fedora 25.
But if the installer is (completely) broken, it might as well be dropped.
Alas, it's not completely broken.
2. The Fedora QA group has 1 mac mini which is very old and is only
used for total install and not dual boot. It would not have found this
The testing should be switched to be a dual-boot test, as it's what
Mac users are more likely to be using (and also a necessity for firmware
The Fedora QA group also has no one using Mac hardware day to
This isn't a problem. There are people using Macs day-to-day, and they report
bugs. The problem here, and I can't emphasise this enough, this problem is
a systemic problem with the installer QA, specifically.
Once the machine is installed, it's usually fairly straight forward to
update packages, downgrade them, and fix hardware specific problems as long
as the device can be booted, and a sufficient amount of hardware is working.
The installer not working, especially when it's a last minute problem,
it becomes a blocker. Do we need a different schedule for installer
3. Out of the people who on this thread said they have Apple
at least 2 have tested Fedora 25 but they both did in a way that would
not have hit the bug but could have been work arounds IF (and ONLY IF)
it had gone out.
I'm pretty sure there's plenty more folks using Fedora on Macs and testing
it than just 2. Again, it shows that the problem is making sure the
installer works. Dogfooding for the rest of the system is done. There are
hardware-specific bug reports being done.
4. Of the people who did have Macs but didn't test, most of them
seemed to have assumed that someone else was testing it for them OR
they didn't know how to test OR they didn't use dual boot so would not
have tested it.
Given that I use my hardware for development (in this case, hardware
enablement), I don't really have the time to constantly wipe and reinstall
the system to test rawhide installers. I guess that most folks that already
have Fedora installed on their machines will simply upgrade the system.
5. Various people think that users of Mac hardware is the group
should focus on but they don't seem to be talking with each other
enough to say how.
IMO, making sure the installer works and the bootloader is correctly installed
would be enough. After that, we can rely on testers from a number of
groups, whether Fedora Mac users, upstream users, etc.
So to me this says that a Macintosh Special User Group would be a
useful tool to answer 2 through 4. They could better find someone who
can rotate through the Fedora QA group to answer 2. They can also work
out what pathways may need to be tested. The people in 3 who are
testing can help the people in 4 also spread out the work. They can
also say which Mac hardware is a good fit for Fedora and which one
isn't. This can better aim people who are coming in but end up with
say some particular hardware from going in and trashing their computer
when it would not have worked without expert help.
Does that sound better than my over the top original rant?
It's better, but I don't think that the problem lies in the QA team,
although some things could be done better there.
The main problem to me seems to be that the installer sees too little
testing, or too little testing when big changes occur, or not a wide
enough breadth of testing scenarios, at the development stage.