On Thu, Nov 17, 2016 at 7:43 AM, Stephen John Smoogen <smooge@xxxxxxxxx> wrote: > 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 > issue. The Fedora QA group also has no one using Mac hardware day to > day. The age is probably not a factor, the bug isn't instigated by firmware peculiarities or old OS X vs new macOS on-disk layout. Either of those would have triggered the bug, but I'll look into it more with kparal before the next cycle. > 3. Out of the people who on this thread said they have Apple hardware, > 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. The only viable work around was an updates.img. A work around involving custom partitioning is a show stopper, I wouldn't subject any Fedora user to that as a work around, GUI or CLI. > 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. Not exactly. I do the same tests every cycle and assumed I had done those tests, and I still think I did, but it's possible there's some unusual nuance in my particular setup that caused me to not hit the bug. But I'm not traveling with my Mac at the moment so I still haven't been able to do an autopsy on what testing I have done, or how the layout of that machine could affect the outcome of the bug. The bug is really straightforward as I understand it, so I'm still kinda mystified how I didn't run into it other than just being distracted with a new non-Mac laptop. > 5. Various people think that users of Mac hardware is the group Fedora > should focus on but they don't seem to be talking with each other > enough to say how. > > 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. There's almost no one really familiar with what we're doing, how it can go wrong, how to clean it up after it's gone correctly or incorrectly. And quite honestly, that bug 1033778 continues to exist despite it clearly violating release criteria, with the upstream excuse that it's the user's own fault, the lack of pride in one's work or contempt for the user, is so incredibly astonishing to me it is not something I care to subject more Mac users to. That bug has no equal. Not gparted, blivet-gui, opensuse or Ubuntu installers, the macOS partitioner or Windows disk management, nothing I've searched high and low for, is that devious in the exact same scenario: None of them make the obvious mistake of presenting a shrink UI for an unsupported file system, and then truncate the volume in an irrecoverable data loss scenario, let alone consider it a feature. It's bizarre. It probably is fair for Mac users to discuss whether mactel-boot's pretty and user friendly ways is a.) better and b.) sustainable, compared to alternatives. And maybe one of them knows python... -- Chris Murphy _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
