Re: Fedora on Macs, removing the release criterion

[Adam Williamson]

On Fri, 2016-11-25 at 15:17 -0700, Chris Murphy wrote:
> On Fri, Nov 25, 2016 at 3:12 PM, Adam Williamson
>  wrote:
> > On Fri, 2016-11-25 at 15:07 -0700, Chris Murphy wrote:
> > > I know the installation tests are
> > > dual boot, following a restore of macOS.
> > 
> > Um. But *you* are the person who 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."
> 
> That was Not Me.

Ah, sorry, you're right. I was misled by the quoting...
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Stephen John Smoogen]

On 25 November 2016 at 17:17, Chris Murphy  wrote:
> On Fri, Nov 25, 2016 at 3:12 PM, Adam Williamson
>  wrote:
>> On Fri, 2016-11-25 at 15:07 -0700, Chris Murphy wrote:
>>> I know the installation tests are
>>> dual boot, following a restore of macOS.
>>
>> Um. But *you* are the person who 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."
>
> That was Not Me.
>
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/Y2H2PXK63EALDXDCBII45OMOBZDNG4HY
>

It was me, and I was wrong on that and other points in this email. At
some point my authoring of that point was removed from the thread so
it got misattributed to Chris. [I am only responding here to qualify
that I was the problem here.]

>
>
> --
> Chris Murphy
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Chris Murphy]

On Fri, Nov 25, 2016 at 3:12 PM, Adam Williamson
 wrote:
> On Fri, 2016-11-25 at 15:07 -0700, Chris Murphy wrote:
>> I know the installation tests are
>> dual boot, following a restore of macOS.
>
> Um. But *you* are the person who 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."

That was Not Me.

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/Y2H2PXK63EALDXDCBII45OMOBZDNG4HY




-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Adam Williamson]

On Fri, 2016-11-25 at 15:07 -0700, Chris Murphy wrote:
> I know the installation tests are
> dual boot, following a restore of macOS.

Um. But *you* are the person who 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."
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Chris Murphy]

On Fri, Nov 25, 2016 at 1:59 PM, Adam Williamson
 wrote:
> On Fri, 2016-11-25 at 13:53 -0700, Chris Murphy wrote:
>> On Fri, Nov 25, 2016 at 7:26 AM, Bastien Nocera  wrote:
>>
>> >
>> > But if the installer is (completely) broken, it might as well be dropped.
>> > Alas, it's not completely broken.
>>
>> Unwieldy, perhaps. It's kinda hard to argue that the installer needs
>> to be this complicated, that Fedora (mainly QA) has to put in so much
>> effort into the installer each cycle testing for bugs in new features
>> and also regressions.
>>
>>
>> >
>> > > 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 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
>> > upgrades).
>>
>> The firmware angle is a very good point.
>
> But you were wrong in the first place. We *do* test dual boot installs
> on that Mac, when we test anything on it. As I said already.

I never said or previously suggested the tests aren't predicated on
dual boot. What I just did today, is reply to someone else making that
assertion without correcting it. I know the installation tests are
dual boot, following a restore of macOS. But my understanding is the
Mac Mini isn't generally running macOS; it's running Fedora. Unless
that system run Mac OS and any update notifications for firmware
updates are responded to and then applied to the system, it's not
getting firmware updates. It's pretty unlikely missing firmware
updates are going to affect Fedora testing, but...


-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Adam Williamson]

On Fri, 2016-11-25 at 09:27 -0500, Bastien Nocera wrote:
> 
> > The problem is that we didn't get around to running the test until the
> > day before the go/no-go. There's a lot of stuff to test, and anything
> > which only one person is likely to test is a risk. Frankly speaking,
> > given how humans work, things that involve digging some piece of
> > hardware you never touch out of a pile and hooking it up to a keyboard
> > and mouse and a monitor and power and network is quite likely to get
> > passed over in favour of something you can run in a VM. Especially if
> > it's 4:30. This is why I have an Unused Arm Devices Pile Of Shame on my
> > desk...
> > 
> > So, partly this is our fault because we could've tested this earlier and
> > didn't. But it's also the case that we really need more redundancy in as
> > much of the required testing as possible.
> 
> Is there any continuous testing done on the images on the installer? Is it
> on real hardware? Is it possible to mock hardware setups? Comparing
> boot setups on working and non-working installations.

I don't know what you mean by "the images on the installer", and I
don't know precisely what you mean by "mock hardware setups". Mock what
about them, in what way, exactly?

To take the specific example we're starting from here, if you mean 'can
we fake up something like an OS X dual boot install on a virtual
machine', the answer is kinda yes, but it's not entirely
straightforward. I actually did this in order to test my fix for the
bug, but as well as faking up a disk layout that approximated an OS X
install, I had to patch anaconda to think the system was a Mac (I just
sabotaged that check to always return True) and provide that patch as
an anaconda updates.img. Otherwise anaconda would've known the system
wasn't a Mac and wouldn't have hit the right code path.

> I think it would be possible to do testing that didn't rely quite as much
> on manual testing, through regression testing on "mock" hardware (a hacked
> up VM with a test disk image), comparing the partition types after 
> installation
> against a working setup, comparing the file lists in the boot partition,
> etc.

We do rather a lot of automated testing of the installer, in fact:

https://openqa.fedoraproject.org/tests/overview?distri=fedora=Rawhide=Fedora-Rawhide-20161125.n.0=1
 is a current Rawhide test run (missing some tests as some images are missing)
https://openqa.fedoraproject.org/tests/overview?distri=fedora=25=1=Fedora-25-20161115.0
 is the Fedora 25 Final automated test run (with all tests)

Those tests are run on every 'nightly' Branched and Rawhide compose,
and on all 'candidate' Branched composes. (We also run the Atomic
ostree installer test on the two-week Atomic nightlies).

Reports from these tests are mailed to this list every day, under the
title "Compose check report". I frequently reply to them with details
about the bugs the tests found.

We could, of course, do a lot *more* of this testing. Just personally
I've got a list of about 30 things I want to add to the test set. But
there's only two and a half people working on the openQA tests, and we
have other stuff to do as well. And of course we have to monitor the
tests that *are* run, investigate the bugs they discover, file them,
and follow up on them.

I should probably note some RH inside baseball at this point: there's a
general theme in RH at present that people would like to have less
divergence between Fedora and RHEL testing processes, specifically it
would be nice to have some of the testing that RH's release test team
does on RHEL builds done on Fedora builds too. Most of those tests run
on Beaker; Fedora technically has a Beaker instance but it's not
sufficiently set up for us to be able to actually run the tests RH has
on it yet. That whole 'oh just get Fedora a Beaker setup, shouldn't be
hard right?!' problem is dumped on tflink's lap at present. Like
everyone else, he has a million other things to do and that one isn't
his highest priority, and he also keeps getting roadblocked on it by
things that are out of his control, AIUI.

Once we have a usable Beaker instance we can try importing some of RH's
tests to it and setting them up to run on Fedora, though I would be
*utterly* unsurprised if that turns out to be a lot more work than it
sounds like.

We currently run all openQA tests on virtual machines. openQA *does* in
fact have the necessary bits to run tests on bare metal - SUSE does
this - but we don't do that and haven't investigated the possibility in
detail yet. Fedora's openQA instances are in PHX, so it'd at least
involve putting new hardware in there, which is its own process and
apparently we don't have unlimited physical *space* there for them.
It's really something we just haven't looked at at all yet.

Beaker is rather more focused on metal testing - it's kinda as much a
'allocate resources on machines with specific properties' system as it
is a testing system, really - but again, we're 

Re: Fedora on Macs, removing the release criterion

[Adam Williamson]

On Fri, 2016-11-25 at 09:26 -0500, Bastien Nocera 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 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
> upgrades).

Chris was incorrect about this. When we actually do have time to run
Mac tests, we test dual boot installs.

> > The Fedora QA group also has no one using Mac hardware day to
> > day.
> 
> 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
> development?

This was a 'last minute bug' in the sense that we *found* it at the
last minute. It was not a 'last minute bug' in the sense that it was
*introduced* at the last minute. The bug was in fact introduced to
blivet master almost exactly a year ago:

https://github.com/rhinstaller/blivet/commit/368a4db6141c7fdcb31ed45fe6be207ccc08ad30

If you're operating under the belief that there is some sort of pell-
mell development process involved here, then you're off-base. That is
not the case. The developers are in fact quite conservative about the
level of change they pull into Branched - more conservative than the
Fedora policies require.

> 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.

Yes. This is exactly the point I argued way down-thread.

It is true to say that not many people test the installer on Macs. Some
people initially argued that we could take this to mean not many people
*use* Fedora on Macs, but I'd argue that's not true. The truth, I
believe, is that a reasonable number of people run Fedora on Macs -
enough to be worth caring about - but very few people test the
installer on Macs. This is an issue specific to Macs, rather than a
'systemic problem with installer development'.

> 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.

This is true only in the sense that, let's be honest, it applies to
almost every piece of code ever. No-one ever tests *everything*. But in
fact we probably test the installer more than we test almost anything
else. It is also, unfortunately, an inherently incredibly complex
codebase with more codepaths than almost anything else, many of which
are not trivial to exercise. Like this one.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Adam Williamson]

On Fri, 2016-11-25 at 13:53 -0700, Chris Murphy wrote:
> On Fri, Nov 25, 2016 at 7:26 AM, Bastien Nocera  wrote:
> 
> > 
> > But if the installer is (completely) broken, it might as well be dropped.
> > Alas, it's not completely broken.
> 
> Unwieldy, perhaps. It's kinda hard to argue that the installer needs
> to be this complicated, that Fedora (mainly QA) has to put in so much
> effort into the installer each cycle testing for bugs in new features
> and also regressions.
> 
> 
> > 
> > > 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 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
> > upgrades).
> 
> The firmware angle is a very good point.

But you were wrong in the first place. We *do* test dual boot installs
on that Mac, when we test anything on it. As I said already.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Chris Murphy]

On Fri, Nov 25, 2016 at 7:26 AM, Bastien Nocera  wrote:

>
> But if the installer is (completely) broken, it might as well be dropped.
> Alas, it's not completely broken.

Unwieldy, perhaps. It's kinda hard to argue that the installer needs
to be this complicated, that Fedora (mainly QA) has to put in so much
effort into the installer each cycle testing for bugs in new features
and also regressions.


>
>> 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 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
> upgrades).

The firmware angle is a very good point. Ostensibly the firmware could
be downloaded, extracted and placed on the FAT32 volume (that Fedora
doesn't use) in the proper location, and NVRAM pointed to that
firmware file, and the firmware will consume it and thereby update the
firmware, without needing macOS. But the path of least resistance is
having a minimal macOS installed, even if it's not otherwise used.




>
>> The Fedora QA group also has no one using Mac hardware day to
>> day.
>
> 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.

Automated testing is problematic because it's not really possible to
virtualize Macs. The various guides for using kvm to virtualize macOS
actually use BIOS firmware, not UEFI, and one of several hacked up
bootloaders (e.g. Chameleon) is use to fake out XNU into booting on
non-Apple hardware. On these systems, there is no EFI System partition
of either the FAT32 or HFS+ variety, so it wouldn't test the installer
behavior we need to test. I don't know what work would be needed to
get Beaker to help do baremetal installations of Fedora on Mac
hardware, and if that is sufficiently not fakey that it'd be a valid
test. So for now it's a manual test. And as the installer regressions
can come at any time, it's a lot of manual testing, and in this
particular case it's not enough to just test if the install media
boots, and the installer launches, an installation writing to the
drive must be done.



> 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
> development?

I'm pretty confident this bug was in Rawhide before F25 branch. I'm
also pretty confident, looking at the Mac I use for testing, that the
small HFS+ volume Anaconda creates and uses as an EFI system partition
only on Macs, was already present for each of the tests I did, and
that's why I never ran into the problem. It looks virtually certain I
did not in fact have completely free space for the installations,
everything but the three Apple creates partitions (FAT32 ESP, macOS
main volume, macOS recovery volume), and the Fedora HFS+ ESP were
deleted, but the presence of that one Fedora HFS+ ESP was seemingly
enough for me to not hit the bug.

So it can't be proven that this is a case of insufficient testing;
it's a case of testing that was imprecise or was just not thorough.
Possibly there should be a single Mac test case that asks for a very
explicit setup, with instructions on how to get to that state using a
path of least resistance, to just test the most minimal "get from A to
B" path, instead of 2-3 or more ways to get there. So at least we have
the most common and simple path tested, and flagged earlier on in the
release cycle that it hasn't been tested.


> 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.

I had no idea macefi stuff was touched. If I'd known this, I'd
probably have been more skeptical and vigilant how I was testing,
instead of becoming more trusting of the installer (and more
complacent of its, in my opinion, inevitable betrayal) - but that's
rather circular logic on my part.

-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Andreas Tunek]

2016-11-25 17:37 GMT+01:00 Stephen John Smoogen :
> On 25 November 2016 at 09:27, Bastien Nocera  wrote:
>>
>>
>> - Original Message -
>>> On 2016-11-17 07:43 AM, Stephen John Smoogen 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.
>>>
>>> This bit isn't quite true. We found the bug *on* that Mac Mini. I'm
>>> worried it's not likely to find *other* bugs that people are likely to
>>> encounter on the systems they actually want to run Fedora on (newer
>>> laptops), but it did find this one.
>>
>> Newer Mac laptops don't have working keyboards or touchpads as they're
>> not connected through USB internally. That's not Fedora's problem though.
>> The problem is if the installer doesn't work when the pre-requisite
>> hardware does.
>>
>>> The problem is that we didn't get around to running the test until the
>>> day before the go/no-go. There's a lot of stuff to test, and anything
>>> which only one person is likely to test is a risk. Frankly speaking,
>>> given how humans work, things that involve digging some piece of
>>> hardware you never touch out of a pile and hooking it up to a keyboard
>>> and mouse and a monitor and power and network is quite likely to get
>>> passed over in favour of something you can run in a VM. Especially if
>>> it's 4:30. This is why I have an Unused Arm Devices Pile Of Shame on my
>>> desk...
>>>
>>> So, partly this is our fault because we could've tested this earlier and
>>> didn't. But it's also the case that we really need more redundancy in as
>>> much of the required testing as possible.
>>
>> Is there any continuous testing done on the images on the installer? Is it
>> on real hardware? Is it possible to mock hardware setups? Comparing
>> boot setups on working and non-working installations.
>>
>> I think it would be possible to do testing that didn't rely quite as much
>> on manual testing, through regression testing on "mock" hardware (a hacked
>> up VM with a test disk image), comparing the partition types after 
>> installation
>> against a working setup, comparing the file lists in the boot partition,
>> etc.
>>
>> I'm surprised that the Anaconda, and blivet developers aren't taking part
>> of this conversation. I'd certainly like them to point out all the ways in
>> which they're already doing what I mentioned, and showing how we could
>> add more test cases.
>
> I am actually not surprised at all. This thread has been another
> soul-sucking, why the heck do I do anything with Fedora type thread.
> After this email I am not paying any more attention to anything on
> this thread either.
>

I kind of fail to see how this thread is "soul-sucking", but then
again there are lots of things I don't understand. But anyway, it is
sad that you feel this way about Fedora.

/Andreas

>
> --
> Stephen J Smoogen.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Stephen John Smoogen]

On 25 November 2016 at 09:27, Bastien Nocera  wrote:
>
>
> - Original Message -
>> On 2016-11-17 07:43 AM, Stephen John Smoogen 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.
>>
>> This bit isn't quite true. We found the bug *on* that Mac Mini. I'm
>> worried it's not likely to find *other* bugs that people are likely to
>> encounter on the systems they actually want to run Fedora on (newer
>> laptops), but it did find this one.
>
> Newer Mac laptops don't have working keyboards or touchpads as they're
> not connected through USB internally. That's not Fedora's problem though.
> The problem is if the installer doesn't work when the pre-requisite
> hardware does.
>
>> The problem is that we didn't get around to running the test until the
>> day before the go/no-go. There's a lot of stuff to test, and anything
>> which only one person is likely to test is a risk. Frankly speaking,
>> given how humans work, things that involve digging some piece of
>> hardware you never touch out of a pile and hooking it up to a keyboard
>> and mouse and a monitor and power and network is quite likely to get
>> passed over in favour of something you can run in a VM. Especially if
>> it's 4:30. This is why I have an Unused Arm Devices Pile Of Shame on my
>> desk...
>>
>> So, partly this is our fault because we could've tested this earlier and
>> didn't. But it's also the case that we really need more redundancy in as
>> much of the required testing as possible.
>
> Is there any continuous testing done on the images on the installer? Is it
> on real hardware? Is it possible to mock hardware setups? Comparing
> boot setups on working and non-working installations.
>
> I think it would be possible to do testing that didn't rely quite as much
> on manual testing, through regression testing on "mock" hardware (a hacked
> up VM with a test disk image), comparing the partition types after 
> installation
> against a working setup, comparing the file lists in the boot partition,
> etc.
>
> I'm surprised that the Anaconda, and blivet developers aren't taking part
> of this conversation. I'd certainly like them to point out all the ways in
> which they're already doing what I mentioned, and showing how we could
> add more test cases.

I am actually not surprised at all. This thread has been another
soul-sucking, why the heck do I do anything with Fedora type thread.
After this email I am not paying any more attention to anything on
this thread either.


-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Bastien Nocera]

- Original Message -

> For that sort of comparison then comparing Macs to any other consumer
> desktop is not possible and is its own category of hardware. I can buy
> 2-3 equivalent memory/cpu/video ASUS systems for a Macbook.

Coo, we might need new computers for the GNOME events box. Can you
point me to the 250$ equivalent for those:
http://www.apple.com/mac-mini/specs/
?

[1]

> They may
> not be as well engineered or as pretty but they are functional and do
> allow me to change out memory and disks much more easily than a Mac.
> Does that mean we shouldn't compare them for working? If we can't then
> we really need to make this a focus early on in a release with people
> wanting it helping out.. 

They work well enough. We have people doing work upstream and downstream
trying to make them work better. Except that we don't spend our time
continuous testing the installer on hardware that we might only have one
model of.

[1]: I hate those "the Macs are too expensive/proprietary/whatever" comments.
Cool, don't buy them, don't use them, but there are plenty of other crapola
hardware to go around in the non-Mac computers we support, and you just don't
see the amount of work done upstream for the undocumented ACPI devices
to make a single button work on your laptop.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Bastien Nocera]

- Original Message -

> The reality is that QA is thinly spread in general. Making this
> blocker "about Macs" is a misleading conclusion, there's a grain of
> truth in it, but it's mistaking the forest for the trees. Next time
> there's a release blocking bug, it'll just be something else.

It's not "about Macs", it's about the installer and its dependencies.
There are other release blocking bugs, and certainly Live images
that don't work are embarrassing, but not being able to install the
system is as bad as it gets.

FWIW, an application included in the Live image that crashes on startup
but has a 0-day update scheduled is a much smaller problem than not
being able to boot the installer, or the installer working as expected.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Bastien Nocera]

- Original Message -
> On 17 November 2016 at 10:22, Bastien Nocera  wrote:
> >
> >
> > - 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 know
> > 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
> issue.

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
upgrades).

> The Fedora QA group also has no one using Mac hardware day to
> day.

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
development?

> 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.

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 Fedora
> 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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 

Re: Fedora on Macs, removing the release criterion

[Bastien Nocera]

- Original Message -
> On 2016-11-17 07:43 AM, Stephen John Smoogen 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.
> 
> This bit isn't quite true. We found the bug *on* that Mac Mini. I'm
> worried it's not likely to find *other* bugs that people are likely to
> encounter on the systems they actually want to run Fedora on (newer
> laptops), but it did find this one.

Newer Mac laptops don't have working keyboards or touchpads as they're
not connected through USB internally. That's not Fedora's problem though.
The problem is if the installer doesn't work when the pre-requisite
hardware does.

> The problem is that we didn't get around to running the test until the
> day before the go/no-go. There's a lot of stuff to test, and anything
> which only one person is likely to test is a risk. Frankly speaking,
> given how humans work, things that involve digging some piece of
> hardware you never touch out of a pile and hooking it up to a keyboard
> and mouse and a monitor and power and network is quite likely to get
> passed over in favour of something you can run in a VM. Especially if
> it's 4:30. This is why I have an Unused Arm Devices Pile Of Shame on my
> desk...
> 
> So, partly this is our fault because we could've tested this earlier and
> didn't. But it's also the case that we really need more redundancy in as
> much of the required testing as possible.

Is there any continuous testing done on the images on the installer? Is it
on real hardware? Is it possible to mock hardware setups? Comparing
boot setups on working and non-working installations.

I think it would be possible to do testing that didn't rely quite as much
on manual testing, through regression testing on "mock" hardware (a hacked
up VM with a test disk image), comparing the partition types after installation
against a working setup, comparing the file lists in the boot partition,
etc.

I'm surprised that the Anaconda, and blivet developers aren't taking part
of this conversation. I'd certainly like them to point out all the ways in
which they're already doing what I mentioned, and showing how we could
add more test cases.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Andreas Tunek]

2016-11-18 15:53 GMT+01:00 Stephen John Smoogen :
> On 18 November 2016 at 02:39, Gerd Hoffmann  wrote:
>>   Hi,
>>
>>> > Apples and oranges. There's no installer on ARM. There's no need to wipe
>>> > all your data on a desktop system that you have one unit of.
>>>
>>> Yes, there is, we support anaconda just like on all the other arches.
>>> It's not as widely used as people like to just consume the disk images
>>> but it is supported and tested across a wide range of boards. We're
>>> even working on adding CI to do this across a lot of boards on a
>>> nightly basis.
>>
>> Yea, but it is still apples and oranges IMO.
>>
>
> And I hate the phrase comparing apples and oranges. Apples and oranges
> are both fruit. They both grow on trees. Apples are closer related to
> roses, but both are members of the rosid family. Both fruit contain
> Vitamin C though oranges have more. I can go on quite a while with
> valid useful comparisons.. but my "you are ranting" buzzer has gone
> off.
>
>> On a arm board you can swap the sdcard in seconds.  Then run tests
>> (images / anaconda / whatever).  Then put back in the original sdcard
>> and things continue to work just fine like they did before you ran the
>> tests.  Try that with a macbook.
>>
>> Also buying a separate device for testing purposes is much less of a
>> problem with arm boards as the costs for that are an order of magnitude
>> lower compared to a mac ...
>>
>
> For that sort of comparison then comparing Macs to any other consumer
> desktop is not possible and is its own category of hardware. I can buy
> 2-3 equivalent memory/cpu/video ASUS systems for a Macbook. They may
> not be as well engineered or as pretty but they are functional and do
> allow me to change out memory and disks much more easily than a Mac.
> Does that mean we shouldn't compare them for working? If we can't then
> we really need to make this a focus early on in a release with people
> wanting it helping out.. 
>
>

I do not really get you point here. I wanted to buy an ASUS but it
didn't work then* (it seems to be solved now).

* https://bugs.freedesktop.org/show_bug.cgi?id=73530

/Andreas

>> cheers,
>>   Gerd
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
>
>
> --
> Stephen J Smoogen.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Andreas Tunek]

2016-11-18 19:37 GMT+01:00 Chris Murphy :
> Options:
> 1. Keep the mactel-boot stuff (pretty but weird), and write up test
> cases specifically to account for the weirdness in particular how to
> reset the state of the computer so it's possible to do clean installs.
> There are a couple of ways to do this. Burden is on Mac testers.
>
> 2. Explore treating Macs like any other kind of EFI computer, which
> means doing no better than Ubuntu or openSUSE where I think they
> largely recommend using rEFInd for their bootmanager instead of GRUB.
> So there's this connotation of being handed off to some other project
> out of the gate. Easier to test, but puts more burden on all Mac
> users.
>
> 3. Apple has hypervisor.framework which is a user space hypervisor
> rather than kernel extension based; and might be a suitable way of
> getting Fedora running on macOS, without depending on VirtualBox.
> Here's a write up on CoreOS using it. I understand Docker is using it
> also.
>
> https://deis.com/blog/2015/get-started-coreos-os-x/
>
> If there's enough interest, 1 & 3 are possible. If it's a case of
> interest being on life support then only 1 is possible which probably
> eventually slides back to 2, where we've been before.
>
>

I would prefer 1 and I will try to to test the install experience in
the F26 dev cycle.

> Chris Murphy
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Chris Murphy]

Options:
1. Keep the mactel-boot stuff (pretty but weird), and write up test
cases specifically to account for the weirdness in particular how to
reset the state of the computer so it's possible to do clean installs.
There are a couple of ways to do this. Burden is on Mac testers.

2. Explore treating Macs like any other kind of EFI computer, which
means doing no better than Ubuntu or openSUSE where I think they
largely recommend using rEFInd for their bootmanager instead of GRUB.
So there's this connotation of being handed off to some other project
out of the gate. Easier to test, but puts more burden on all Mac
users.

3. Apple has hypervisor.framework which is a user space hypervisor
rather than kernel extension based; and might be a suitable way of
getting Fedora running on macOS, without depending on VirtualBox.
Here's a write up on CoreOS using it. I understand Docker is using it
also.

https://deis.com/blog/2015/get-started-coreos-os-x/

If there's enough interest, 1 & 3 are possible. If it's a case of
interest being on life support then only 1 is possible which probably
eventually slides back to 2, where we've been before.


Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Towards a targeted hardware list [was Re: Fedora on Macs, removing the release criterion]

[Josh Boyer]

On Fri, Nov 18, 2016 at 9:36 AM, Matthew Miller
 wrote:
> On Tue, Nov 15, 2016 at 09:01:52AM -0800, Adam Williamson wrote:
>> I would not be at all surprised to see a response to 1) be an effort to
>> define some specific hardware configurations that Workstation targets.
>
> Not completely by coincidence, I raised this at a Red Hat meeting this
> week. Since Red Hat is our primary sponsor and all, there's long (like,
> for twenty years) been the community knowledge that if you use the
> laptops Red Hat buys its employees, you have better odds. Red Hat IT is
> going through the process of standardizing the company on some select
> models (I don't know the details yet), and I asked if we could make
> that list public in Fedora — and was told "absolutely".
>
> So, that could be the foundation of a list of "targeted" models (I
> don't want to say "supported", since that's so loaded). Obviously, this
> is Red Hat bringing their particular stake to the table — or to use
> Smooge's metaphor, bringing some potatoes to the soup. I doubt that
> without a significant deal from Apple (which is vanishingly unlikely!)
> we would include Mac support in that, though, and it's probably not
> going to even include all of the PC hardware Fedora would like to run
> well on, so if we want that, we do need... more veggies.

It would be interesting if we, as a Project, could reach out to other
vendors and see if we can get some collaboration going around Fedora
support for their hardware.  Dell would seem to be a prime candidate.
Their commitment to the UEFI firmware update mechanisms has been a
fantastic example.

josh
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Stephen John Smoogen]

On 18 November 2016 at 02:39, Gerd Hoffmann  wrote:
>   Hi,
>
>> > Apples and oranges. There's no installer on ARM. There's no need to wipe
>> > all your data on a desktop system that you have one unit of.
>>
>> Yes, there is, we support anaconda just like on all the other arches.
>> It's not as widely used as people like to just consume the disk images
>> but it is supported and tested across a wide range of boards. We're
>> even working on adding CI to do this across a lot of boards on a
>> nightly basis.
>
> Yea, but it is still apples and oranges IMO.
>

And I hate the phrase comparing apples and oranges. Apples and oranges
are both fruit. They both grow on trees. Apples are closer related to
roses, but both are members of the rosid family. Both fruit contain
Vitamin C though oranges have more. I can go on quite a while with
valid useful comparisons.. but my "you are ranting" buzzer has gone
off.

> On a arm board you can swap the sdcard in seconds.  Then run tests
> (images / anaconda / whatever).  Then put back in the original sdcard
> and things continue to work just fine like they did before you ran the
> tests.  Try that with a macbook.
>
> Also buying a separate device for testing purposes is much less of a
> problem with arm boards as the costs for that are an order of magnitude
> lower compared to a mac ...
>

For that sort of comparison then comparing Macs to any other consumer
desktop is not possible and is its own category of hardware. I can buy
2-3 equivalent memory/cpu/video ASUS systems for a Macbook. They may
not be as well engineered or as pretty but they are functional and do
allow me to change out memory and disks much more easily than a Mac.
Does that mean we shouldn't compare them for working? If we can't then
we really need to make this a focus early on in a release with people
wanting it helping out.. 


> cheers,
>   Gerd
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Towards a targeted hardware list [was Re: Fedora on Macs, removing the release criterion]

[Matthew Miller]

On Tue, Nov 15, 2016 at 09:01:52AM -0800, Adam Williamson wrote:
> I would not be at all surprised to see a response to 1) be an effort to
> define some specific hardware configurations that Workstation targets.

Not completely by coincidence, I raised this at a Red Hat meeting this
week. Since Red Hat is our primary sponsor and all, there's long (like,
for twenty years) been the community knowledge that if you use the
laptops Red Hat buys its employees, you have better odds. Red Hat IT is
going through the process of standardizing the company on some select
models (I don't know the details yet), and I asked if we could make
that list public in Fedora — and was told "absolutely".

So, that could be the foundation of a list of "targeted" models (I
don't want to say "supported", since that's so loaded). Obviously, this
is Red Hat bringing their particular stake to the table — or to use
Smooge's metaphor, bringing some potatoes to the soup. I doubt that
without a significant deal from Apple (which is vanishingly unlikely!)
we would include Mac support in that, though, and it's probably not
going to even include all of the PC hardware Fedora would like to run
well on, so if we want that, we do need... more veggies.

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Gerd Hoffmann]

  Hi,

> > Apples and oranges. There's no installer on ARM. There's no need to wipe
> > all your data on a desktop system that you have one unit of.
> 
> Yes, there is, we support anaconda just like on all the other arches.
> It's not as widely used as people like to just consume the disk images
> but it is supported and tested across a wide range of boards. We're
> even working on adding CI to do this across a lot of boards on a
> nightly basis.

Yea, but it is still apples and oranges IMO.

On a arm board you can swap the sdcard in seconds.  Then run tests
(images / anaconda / whatever).  Then put back in the original sdcard
and things continue to work just fine like they did before you ran the
tests.  Try that with a macbook.

Also buying a separate device for testing purposes is much less of a
problem with arm boards as the costs for that are an order of magnitude
lower compared to a mac ...

cheers,
  Gerd
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Chris Murphy]

On Thu, Nov 17, 2016 at 11:29 AM, Adam Williamson
 wrote:
> On 2016-11-17 11:22 AM, Chris Murphy wrote:
>>
>> For some time now, the system partition is not HFS+ and not
>> identifiable as HFS+ and cannot be mounted on Linux in any way. The
>> default installation uses Core Storage (Apple's LVM like thing), and
>> even converts non-Core Storage systems upon upgrade so that they use
>> it. The one thing that remains HFS+ on these systems is the Recovery
>> HD partition, which is approximately like a hybrid between a Linux
>> /boot volume and Live image.
>
>
> That's an interesting wrinkle, thanks for the info. But AFAICS it shouldn't
> make a huge amount of difference; blivet would, I think, consider the
> recovery partition to be a 'macefi' partition and go wrong still. Welp, I
> guess we'll see when you try it out more.

Right and I'd be shocked if it weren't journaled HFS+, but it's
possible it isn't because all it contains is one or two disk images
which are what actually get booted. It's not a read write volume so
there's no need for it be journaled. So it might be that the
installation succeeded because it used the recovery hd as macefi. But
what I expect is that I had a stale layout with a Linux HFS+ ESP that
was recycled.


-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Adam Williamson]

On 2016-11-17 11:22 AM, Chris Murphy wrote:

For some time now, the system partition is not HFS+ and not
identifiable as HFS+ and cannot be mounted on Linux in any way. The
default installation uses Core Storage (Apple's LVM like thing), and
even converts non-Core Storage systems upon upgrade so that they use
it. The one thing that remains HFS+ on these systems is the Recovery
HD partition, which is approximately like a hybrid between a Linux
/boot volume and Live image.


That's an interesting wrinkle, thanks for the info. But AFAICS it 
shouldn't make a huge amount of difference; blivet would, I think, 
consider the recovery partition to be a 'macefi' partition and go wrong 
still. Welp, I guess we'll see when you try it out more.

--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Chris Murphy]

On Thu, Nov 17, 2016 at 10:50 AM, Adam Williamson
 wrote:
> On 2016-11-17 10:30 AM, Chris Murphy wrote:
>>
>> 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.
>
>
> What I suspect is that you didn't do a fresh dual-boot install, but always
> installed over an existing Fedora install. I did not look into exactly what
> the old code does in that case.

That is the most logical explanation, but the thing is, I previously
have always done clean install tests.


> I'm fairly sure in that case it would identify *both* the real existing
> 'macefi' partition and the OS X system partition as 'macefi' partitions.

For some time now, the system partition is not HFS+ and not
identifiable as HFS+ and cannot be mounted on Linux in any way. The
default installation uses Core Storage (Apple's LVM like thing), and
even converts non-Core Storage systems upon upgrade so that they use
it. The one thing that remains HFS+ on these systems is the Recovery
HD partition, which is approximately like a hybrid between a Linux
/boot volume and Live image. There's enough ambiguity here that I
simply can't account for how I missed it, except that there was
something about the system that was not "out of the box"  - otherwise
it's pretty clear I'd have hit the bug. But for this to go one for an
entire release... quite unexpected. Usually I install Rawhide a couple
times per year, and either alpha or beta or both, cleanly. It is a
side effect of my entire mantra here, is that the installer is just
not trustworthy and has all kinds of regressions (not just bugs for
new features).


> But
> it only needs to pick *one* of them to be /boot/efi. I did not bother
> figuring out how it makes that decision. My best guess is that it happens to
> pick the 'real' macefi partition in that case - either reliably, or it's
> unpredictable/random but it happened to pick the right one in your case -
> and then the install would work OK.

It must've picked a previous LInux HFS+ ESP, which I normally
obliterate when doing testing for exactly the reason in this bug. I'm
aware that the code tries to reuse this partition rather than create a
new one. And aware that it won't use the FAT32 one.



-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Adam Williamson]

On 2016-11-17 10:30 AM, Chris Murphy wrote:

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.


What I suspect is that you didn't do a fresh dual-boot install, but 
always installed over an existing Fedora install. I did not look into 
exactly what the old code does in that case.


I'm fairly sure in that case it would identify *both* the real existing 
'macefi' partition and the OS X system partition as 'macefi' partitions. 
But it only needs to pick *one* of them to be /boot/efi. I did not 
bother figuring out how it makes that decision. My best guess is that it 
happens to pick the 'real' macefi partition in that case - either 
reliably, or it's unpredictable/random but it happened to pick the right 
one in your case - and then the install would work OK.


This is just conjecture, though. I'm interested to see your results.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Chris Murphy]

On Thu, Nov 17, 2016 at 7:43 AM, Stephen John Smoogen  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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Chris Murphy]

On Thu, Nov 17, 2016 at 7:09 AM, Stephen John Smoogen  wrote:
> On 17 November 2016 at 09:08, Bastien Nocera  wrote:
>>
>>
>> - Original Message -
>>> On 11 November 2016 at 03:20, Andreas Tunek  wrote:
>>> >
>>> >
>>> > As a mac owner (although one that is not very well supported by
>>> > Linux*) I really appreciate the fact that Fedora works. And saying you
>>> > do not want to support that hardware anymore just because you found a
>>> > regression/bug is kind of lame.
>>>
>>> You are reading that wrong. The problem isn't that we don't want to
>>> support Mac hardware, we are finding we can't support Mac hardware to
>>> the level that it blocks a release because there are not enough people
>>> testing the hardware in a fashion that finds blocker level bugs.
>>>
>>> This is where you and other Mac users can and MUST help out. Fedora is
>>> a stone soup. Unless people bring some amount of work to the pot, what
>>> they get out is water flavoured gravel.  You can bring the spice and
>>> aroma of a Mac hardware.. but if you don't then it doesn't mean that
>>> we can wait until someone else does.
>>
>> That's an unfair characterisation of the problem. There are certainly plenty
>> of people testing out Fedora on Macs. I'm guessing most of those folks have
>> a single machine that they use Fedora on. You're asking them to do continuous
>> testing of the installer, which the installer team is much more likely to be
>> able to do.
>>
>
> 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.

The reality is that QA is thinly spread in general. Making this
blocker "about Macs" is a misleading conclusion, there's a grain of
truth in it, but it's mistaking the forest for the trees. Next time
there's a release blocking bug, it'll just be something else.



-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Stephen John Smoogen]

On 17 November 2016 at 11:40, Josh Boyer  wrote:
> On Thu, Nov 17, 2016 at 11:31 AM, Adam Williamson
>  wrote:
>> On 2016-11-17 07:43 AM, Stephen John Smoogen 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.
>>
>>
>> This bit isn't quite true. We found the bug *on* that Mac Mini. I'm worried
>> it's not likely to find *other* bugs that people are likely to encounter on
>> the systems they actually want to run Fedora on (newer laptops), but it did
>> find this one.
>>
>> The problem is that we didn't get around to running the test until the day
>> before the go/no-go. There's a lot of stuff to test, and anything which only
>> one person is likely to test is a risk. Frankly speaking, given how humans
>> work, things that involve digging some piece of hardware you never touch out
>> of a pile and hooking it up to a keyboard and mouse and a monitor and power
>> and network is quite likely to get passed over in favour of something you
>> can run in a VM. Especially if it's 4:30. This is why I have an Unused Arm
>> Devices Pile Of Shame on my desk...
>>
>> So, partly this is our fault because we could've tested this earlier and
>> didn't. But it's also the case that we really need more redundancy in as
>> much of the required testing as possible.
>
> I disagree with your assessment that it is your (Fedora QA's) fault.
> It is not.  It is a resource issue that the community beyond just that
> of Fedora QA can clearly help with.  This is not a Fedora QA failure.


While I was wrong in 2, I also agree with Josh on this. There is a
human resource issue where people who are interested in that
particular product can help in.

> josh
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Josh Boyer]

On Thu, Nov 17, 2016 at 11:31 AM, Adam Williamson
 wrote:
> On 2016-11-17 07:43 AM, Stephen John Smoogen 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.
>
>
> This bit isn't quite true. We found the bug *on* that Mac Mini. I'm worried
> it's not likely to find *other* bugs that people are likely to encounter on
> the systems they actually want to run Fedora on (newer laptops), but it did
> find this one.
>
> The problem is that we didn't get around to running the test until the day
> before the go/no-go. There's a lot of stuff to test, and anything which only
> one person is likely to test is a risk. Frankly speaking, given how humans
> work, things that involve digging some piece of hardware you never touch out
> of a pile and hooking it up to a keyboard and mouse and a monitor and power
> and network is quite likely to get passed over in favour of something you
> can run in a VM. Especially if it's 4:30. This is why I have an Unused Arm
> Devices Pile Of Shame on my desk...
>
> So, partly this is our fault because we could've tested this earlier and
> didn't. But it's also the case that we really need more redundancy in as
> much of the required testing as possible.

I disagree with your assessment that it is your (Fedora QA's) fault.
It is not.  It is a resource issue that the community beyond just that
of Fedora QA can clearly help with.  This is not a Fedora QA failure.

josh
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Adam Williamson]

On 2016-11-17 07:43 AM, Stephen John Smoogen 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.


This bit isn't quite true. We found the bug *on* that Mac Mini. I'm 
worried it's not likely to find *other* bugs that people are likely to 
encounter on the systems they actually want to run Fedora on (newer 
laptops), but it did find this one.


The problem is that we didn't get around to running the test until the 
day before the go/no-go. There's a lot of stuff to test, and anything 
which only one person is likely to test is a risk. Frankly speaking, 
given how humans work, things that involve digging some piece of 
hardware you never touch out of a pile and hooking it up to a keyboard 
and mouse and a monitor and power and network is quite likely to get 
passed over in favour of something you can run in a VM. Especially if 
it's 4:30. This is why I have an Unused Arm Devices Pile Of Shame on my 
desk...


So, partly this is our fault because we could've tested this earlier and 
didn't. But it's also the case that we really need more redundancy in as 
much of the required testing as possible.

--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Stephen John Smoogen]

On 17 November 2016 at 10:22, Bastien Nocera  wrote:
>
>
> - 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 know
> 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.

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.

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.

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.

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.

Does that sound better than my over the top original rant?

-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[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 know
if you want a list of hardware enablement I've done on Macs over the years.

> For example, in the past 4 years the ARM builders have been nothing
> but a pain in the ass, but they are kept going because there are
> people who banded together and do a lot of the work. Yes there are the
> various people who show up and expect XYZ board to be magically
> supported but there are still a lot of people who show up, test the
> bugs on what they find important to them and those boards get covered.
> If the Mac is important enough, pick a couple of models which are what
> you are going to focus on and season the pot.

Apples and oranges. There's no installer on ARM. There's no need to wipe
all your data on a desktop system that you have one unit of.

The *installer* breaking is a very different proposition to whatever piece
of software breaking. We don't release updated installers. Making it 
uninstallable
means people will just not use any of our software. And it's even worse
when 1) it was supported and working 2) it probably worked better than
most other distributions.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Peter Robinson]

> 
>> 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 know
> if you want a list of hardware enablement I've done on Macs over the years.
>
>> For example, in the past 4 years the ARM builders have been nothing
>> but a pain in the ass, but they are kept going because there are
>> people who banded together and do a lot of the work. Yes there are the
>> various people who show up and expect XYZ board to be magically
>> supported but there are still a lot of people who show up, test the
>> bugs on what they find important to them and those boards get covered.
>> If the Mac is important enough, pick a couple of models which are what
>> you are going to focus on and season the pot.
>
> Apples and oranges. There's no installer on ARM. There's no need to wipe
> all your data on a desktop system that you have one unit of.

Yes, there is, we support anaconda just like on all the other arches.
It's not as widely used as people like to just consume the disk images
but it is supported and tested across a wide range of boards. We're
even working on adding CI to do this across a lot of boards on a
nightly basis.

> The *installer* breaking is a very different proposition to whatever piece
> of software breaking. We don't release updated installers. Making it 
> uninstallable
> means people will just not use any of our software. And it's even worse
> when 1) it was supported and working 2) it probably worked better than
> most other distributions.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Stephen John Smoogen]

On 17 November 2016 at 09:08, Bastien Nocera  wrote:
>
>
> - Original Message -
>> On 11 November 2016 at 03:20, Andreas Tunek  wrote:
>> >
>> >
>> > As a mac owner (although one that is not very well supported by
>> > Linux*) I really appreciate the fact that Fedora works. And saying you
>> > do not want to support that hardware anymore just because you found a
>> > regression/bug is kind of lame.
>>
>> You are reading that wrong. The problem isn't that we don't want to
>> support Mac hardware, we are finding we can't support Mac hardware to
>> the level that it blocks a release because there are not enough people
>> testing the hardware in a fashion that finds blocker level bugs.
>>
>> This is where you and other Mac users can and MUST help out. Fedora is
>> a stone soup. Unless people bring some amount of work to the pot, what
>> they get out is water flavoured gravel.  You can bring the spice and
>> aroma of a Mac hardware.. but if you don't then it doesn't mean that
>> we can wait until someone else does.
>
> That's an unfair characterisation of the problem. There are certainly plenty
> of people testing out Fedora on Macs. I'm guessing most of those folks have
> a single machine that they use Fedora on. You're asking them to do continuous
> testing of the installer, which the installer team is much more likely to be
> able to do.
>

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.

For example, in the past 4 years the ARM builders have been nothing
but a pain in the ass, but they are kept going because there are
people who banded together and do a lot of the work. Yes there are the
various people who show up and expect XYZ board to be magically
supported but there are still a lot of people who show up, test the
bugs on what they find important to them and those boards get covered.
If the Mac is important enough, pick a couple of models which are what
you are going to focus on and season the pot.


-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Bastien Nocera]

- Original Message -
> On 11 November 2016 at 03:20, Andreas Tunek  wrote:
> >
> >
> > As a mac owner (although one that is not very well supported by
> > Linux*) I really appreciate the fact that Fedora works. And saying you
> > do not want to support that hardware anymore just because you found a
> > regression/bug is kind of lame.
> 
> You are reading that wrong. The problem isn't that we don't want to
> support Mac hardware, we are finding we can't support Mac hardware to
> the level that it blocks a release because there are not enough people
> testing the hardware in a fashion that finds blocker level bugs.
> 
> This is where you and other Mac users can and MUST help out. Fedora is
> a stone soup. Unless people bring some amount of work to the pot, what
> they get out is water flavoured gravel.  You can bring the spice and
> aroma of a Mac hardware.. but if you don't then it doesn't mean that
> we can wait until someone else does.

That's an unfair characterisation of the problem. There are certainly plenty
of people testing out Fedora on Macs. I'm guessing most of those folks have
a single machine that they use Fedora on. You're asking them to do continuous
testing of the installer, which the installer team is much more likely to be
able to do.

There's regular hardware giveaways within Red Hat, when departments that do
use Macs give them away when they do their hardware refresh. So it would be
possible to test this out at the root.

I installed Fedora 25 on the MacBook Pro that was given to me, but I upgraded
it via gnome-software.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Przemek Klosowski]

On 11/14/2016 05:20 PM, Andreas Tunek wrote:

If you are going to remove functionality/hardware support you should
at least announce it someway otherwise people (users and contributors)
will lose faith in your project.


I do not have an agenda here---I am just a Fedora-using grandpa on the 
sidelines, listening to this discussion. I have a comment for you, which 
I hope you take into consideration without taking it personally: please 
consider that your position comes across as demanding that Fedora 
supports Macs. Be careful using phrases like 'you should' and 'your 
project'; I think of Fedora as our project, on which we should do things 
to make it better.
Adam in particular is working hard on many useful projects; I personally 
would be very careful demanding things of him, because my own 
contributions are meager comparatively.


My sincere greetings, and respects


p.k.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Chris Murphy]

On Tue, Nov 15, 2016 at 9:45 AM, Josh Boyer  wrote:
> On Tue, Nov 15, 2016 at 12:19 PM, Chris Murphy  
> wrote:

>> What's in place right now is a release blocking criterion that was not
>> being met, so the release was blocked. The criterion is not a secret
>> or new, the process is not secret or new, yet somehow there's an 'oh
>> shit we're blocking the entire release just for Macs?!' reaction, as
>
> I'm not surprised.  I simply disagree with the decision.

Which decision? Upholding the criterion by blocking the release, or
the creation of the criterion to begin with? I'm not aware of a
procedure to just ignore criteria due to lack of testing for the
current release. Arguing dispensing with a lack of testing to demote a
criterion makes sense but doing.


>
>> if there's something fundamentally different compared to any other
>> time we've had a last minute blocker bug that only affects a minority.
>
> There is.  Because we've genuinely waffled about impacted majority a
> number of times and released anyway.

Waffling happens with gray areas, and the natural stinginess in doling
out blockers that develops close to the release. But this wasn't a
gray area.




-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Adam Williamson]

On Tue, 2016-11-15 at 10:28 -0800, Chris Murphy wrote:
> 

> I'm not counting change sets. I'm counting user distinguishable UIs,
> and those are four distinctly different interfaces and experiences and
> they each even have their own names:
> oldui
> newui auto
> newui custom
> blivet-gui

I understand your enumeration. However, I disagree that it demonstrates
this:

> That is a lot of churn in UI/Ux in 5 years

Because:

1) You're using a classic bogus statistics trick: choosing misleading
boundaries. You can only claim "in 5 years" by *just happening* to set
your initial boundary at the precise point where we switched from oldui
to newui. oldui had, at that point, existed for, like, a decade. So
even accepting your enumeration, it would be equally valid to say 'four
UIs in 15 years' (or whatever the precise number is). Which doesn't
sound nearly as bad, does it?

2) 'newui auto' and 'newui custom' are really different elements of the
same interface. They were designed that way. You can't legitimately
count them separately for the purpose of illustrating 'churn', because
they can only properly be counted separately for that purpose if we
first made one, then changed our minds and made the other. That is not
what happened. Both were elements of the newUI re-design, which was a
single unitary concept. Both exist right in the initial whiteboards for
newUI. It's wrong to count them as two things for the purpose of
claiming a total of 4 as an illustration of 'churn'. Just wrong.

3) We have not in fact built an installer interface which involves
blivet-gui yet and AFAIK no plans to do so are finalized. So once
again, your boundaries are suspect: how can you count something that
hasn't happened yet in your 'five year' timeframe?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Chris Murphy]

On Tue, Nov 15, 2016 at 9:00 AM, Adam Williamson
 wrote:



> It is entirely possible, of course, to be 'greatly improved' and still
> 'excessive'. You didn't argue that the installer is too buggy, you
> argued that it hasn't got any less buggy ('stability or blocker bugs')
> since Fedora 17. So now you're completely changing your premise.

You might be correct. AcceptedBlocker for anaconda+python-blivet

Fedora 25 = 9

Fedora 24 = 5

Fedora 23 = 23

Fedora 22 = 20

Feodra 21 = 19

Fedora 20 = 42



> Still, we've been round this goat rodeo many times, and I know you know
> perfectly well why anaconda is susceptible to bugs: because it does a
> lot of stuff. Have you considered how many bugs you'd find if you only
> tested the same things in anaconda that you can actually *do at all* in
> other distributions?

YaST does pretty much all the things Anaconda can do. It has a mind
numbing interface that requires contortions to get through. But
there's almost zero complaints about the installer in suseland. It is
widely trusted. I also haven't run into data loss bugs in it while
actively trying to hit them.

>>
>> OK well the most obvious would be the four installer UIs in 5 years,
>> should blivet-gui get integrated in Fedora 26. The old bottom UI is
>> dumped (1), and replaced with automatic partitioning (2) and custom's
>> top down UI (3). Then the idea becomes the top down UI isn't doing
>> what users want so add a new bottom up UI (4).
>
> Uh, that's some strange counting you've got there, bub. Your '1', '2'
> and '3' are actually all the same single change: newUI. And oldUI still
> effectively had a 'guided workflow' and a 'custom workflow'; they were
> just presented slightly differently (linearly).

I'm not counting change sets. I'm counting user distinguishable UIs,
and those are four distinctly different interfaces and experiences and
they each even have their own names:
oldui
newui auto
newui custom
blivet-gui

That is a lot of churn in UI/Ux in 5 years. And I've already gone on
to disagree with the including of the 4th one in the installer proper,
it just makes it all the more unwieldy. How many UI's does an
installer need jokes forthcoming.


-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Adam Williamson]

On Tue, 2016-11-15 at 19:01 +0100, Andreas Tunek wrote:
> I must have missed that. Sorry. Is there a wiki where you can see what
> has been tested like the "normal" test days?

Well, yes. That's what the results pages, that all the announcement
emails link to, show. The announcement emails also link to:

https://www.happyassassin.net/testcase_stats/25/

which shows you a longitudinal view of which tests have been run for
which validation events.

If you look at https://www.happyassassin.net/testcase_stats/25/Installation.html
(scroll to the bottom), you'll see no-one filed a result for
'QA:Testcase_dualboot_with_OSX' until the second release candidate.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Adam Williamson]

On Tue, 2016-11-15 at 19:00 +0100, Andreas Tunek wrote:
> 2016-11-15 17:31 GMT+01:00 Adam Williamson :
> > On Tue, 2016-11-15 at 17:27 +0100, Andreas Tunek wrote:
> > > Maybe the release criteria should reflect that then. Right now it says
> > > that mac support is a criteria for release.
> > 
> > You do remember the topic of this thread, right?
> 
> There is a difference in changing the criteria for F25 and F26+.

I'm now completely lost and have absolutely no idea what it is you
actually *want* any more.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Andreas Tunek]

2016-11-15 17:30 GMT+01:00 Adam Williamson :
> On Tue, 2016-11-15 at 17:15 +0100, Andreas Tunek wrote:
>> 2016-11-15 8:43 GMT+01:00 Adam Williamson :
>> > On Tue, 2016-11-15 at 07:35 +0100, Andreas Tunek wrote:
>> > > If something is in the release criteria I expect the feature to be
>> > > present in the release. If the feature in question has worked for ~20
>> > > Fedora releases it is not my first priority to test, unless there is
>> > > specific communication otherwise, like specific "Mac install testing
>> > > days" (which to my knowledge there hasn't been).
>> >
>> > As a general rule of thumb, stuff that gets tested keeps working. Stuff
>> > that doesn't breaks. It's why we test stuff.
>> > --
>>
>> For me as a user it is really difficult to know what has been tested
>> and what needs more testing. The test days are really good so you know
>> what to focus on.
>
> We haven't done an 'installer Test Day' for a while because it's not a
> typical fit for a Test Day. Test Days are usually for testing out some
> big new feature or major change in a release which is a kind of unitary
> thing. We haven't had a single specific pinpointable 'major change' in
> the installer for several releases now; rather its behaviour tends to
> evolve gradually with smaller changes that land frequently, and changes
> to the behaviour of other components it depends upon.
>
> What we *do* have for the installer is release validation testing. We
> announce all the release validation testing events to this list, and
> the OSX test is listed right there. I have sent out pleas multiple
> times this cycle for people to help test all the Alpha/Beta/Final
> priority validation tests.
>

I must have missed that. Sorry. Is there a wiki where you can see what
has been tested like the "normal" test days?


> Did these not reach you, or is the process too difficult to follow?
> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Andreas Tunek]

2016-11-15 17:31 GMT+01:00 Adam Williamson :
> On Tue, 2016-11-15 at 17:27 +0100, Andreas Tunek wrote:
>> Maybe the release criteria should reflect that then. Right now it says
>> that mac support is a criteria for release.
>
> You do remember the topic of this thread, right?

There is a difference in changing the criteria for F25 and F26+.

> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Josh Boyer]

On Tue, Nov 15, 2016 at 12:19 PM, Chris Murphy  wrote:
> On Tue, Nov 15, 2016 at 4:45 AM, Josh Boyer  wrote:
> On Mon, Nov 14, 2016 at 4:52 PM, Andreas Tunek  
> wrote:
>>> How do you fix it if you can't install the release? Do you make a new
>>> release with all the testing again (to make sure you do not have other
>>> regression bugs)?
>>
>> Anaconda has updates.img, which might be usable post-release.  Barring
>> that, there are the update respins that other community members do.
>> Pretending those don't exist seems silly.
>
> The silly pretense I see is the notion there's an idea how to do this,
> let alone a policy or procedure in place.
>
> What's in place right now is a release blocking criterion that was not
> being met, so the release was blocked. The criterion is not a secret
> or new, the process is not secret or new, yet somehow there's an 'oh
> shit we're blocking the entire release just for Macs?!' reaction, as

I'm not surprised.  I simply disagree with the decision.

> if there's something fundamentally different compared to any other
> time we've had a last minute blocker bug that only affects a minority.

There is.  Because we've genuinely waffled about impacted majority a
number of times and released anyway.

> Because of the monumental testing that happens, there's a really good
> chance a last minute blocker ends up affecting only a minority. That
> is how the process works. All you have to do is read the list of
> release criteria and realize that it's a very consensual process where
> an affected minority can block the entire release. Unsurprising. Not
> news.
>
> I also think it's a silly pretense that we'd be having this
> conversation if the exact same problem happened with Windows dual
> boot. There'd be no serious proposal to drop Windows dual boot as a
> release blocking criterion.

It's not pretense.  There are, numerically, far more Windows laptops
than there are Macs.  The gap is closing, but it's still the case.

> To test that hypothesis, I propose a new policy that requires 100% of
> test cases which are attached to a release blocking criterion, shall
> have been performed by some milestone, perhaps sometime between beta
> GA and final freeze.  If the test hasn't been done, the applicable
> criterion is put in a one cycle abeyance, i.e. bugs found to violate
> the suspended criterion will not be accepted as blockers for final for
> the release.

I like this proposal.  It seems to make forward progress on the things
I'm actually concerned about, which is lack of resources to test all
the criteria.  By moving it up, we catch the gap earlier.

> Another possibility is that maybe the Mac and Windows criterion should
> be beta milestones. QA always says nothing prevents earlier testing,
> but in reality a bunch of final tests don't happen until well after
> final freeze, it's just the way it goes in Fedoraland.

That seems like a more specific tweak on your proposal above.

 Lastly, support is a very loaded word, particularly in the context of
 a community driven project.  We actually do not have an x86 equivalent
 of the ARM supported-boards list, so it's completely random as to what
 laptops and desktops are tested and prioritized.  That might be
 something to focus on going forward.
>>>
>>> It has been in the release critera that you should be able to install
>>> on macs and it has worked for a very long time. If you are going to
>>> remove that support you should really let people know in advance (not
>>> a week before release).
>>
>> Again, nobody is saying "remove support".  We're saying "fix it later".
>
> The blocker hammer is what's been meant by support for a long time
> now. There is no mechanism for supporting a thing and fixing it later.

Untrue in the general sense.  We have updates that fix things later
all the time.  Otherwise we'd never ship the literal gigabytes of
updates we do during a release.

> When it's not important to block on, it doesn't get fixed.

Also untrue in the general sense.

josh
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Chris Murphy]

On Tue, Nov 15, 2016 at 4:45 AM, Josh Boyer  wrote:
On Mon, Nov 14, 2016 at 4:52 PM, Andreas Tunek  wrote:
>> How do you fix it if you can't install the release? Do you make a new
>> release with all the testing again (to make sure you do not have other
>> regression bugs)?
>
> Anaconda has updates.img, which might be usable post-release.  Barring
> that, there are the update respins that other community members do.
> Pretending those don't exist seems silly.

The silly pretense I see is the notion there's an idea how to do this,
let alone a policy or procedure in place.

What's in place right now is a release blocking criterion that was not
being met, so the release was blocked. The criterion is not a secret
or new, the process is not secret or new, yet somehow there's an 'oh
shit we're blocking the entire release just for Macs?!' reaction, as
if there's something fundamentally different compared to any other
time we've had a last minute blocker bug that only affects a minority.
Because of the monumental testing that happens, there's a really good
chance a last minute blocker ends up affecting only a minority. That
is how the process works. All you have to do is read the list of
release criteria and realize that it's a very consensual process where
an affected minority can block the entire release. Unsurprising. Not
news.

I also think it's a silly pretense that we'd be having this
conversation if the exact same problem happened with Windows dual
boot. There'd be no serious proposal to drop Windows dual boot as a
release blocking criterion.

To test that hypothesis, I propose a new policy that requires 100% of
test cases which are attached to a release blocking criterion, shall
have been performed by some milestone, perhaps sometime between beta
GA and final freeze.  If the test hasn't been done, the applicable
criterion is put in a one cycle abeyance, i.e. bugs found to violate
the suspended criterion will not be accepted as blockers for final for
the release.

Another possibility is that maybe the Mac and Windows criterion should
be beta milestones. QA always says nothing prevents earlier testing,
but in reality a bunch of final tests don't happen until well after
final freeze, it's just the way it goes in Fedoraland.



>
>>> Lastly, support is a very loaded word, particularly in the context of
>>> a community driven project.  We actually do not have an x86 equivalent
>>> of the ARM supported-boards list, so it's completely random as to what
>>> laptops and desktops are tested and prioritized.  That might be
>>> something to focus on going forward.
>>
>> It has been in the release critera that you should be able to install
>> on macs and it has worked for a very long time. If you are going to
>> remove that support you should really let people know in advance (not
>> a week before release).
>
> Again, nobody is saying "remove support".  We're saying "fix it later".

The blocker hammer is what's been meant by support for a long time
now. There is no mechanism for supporting a thing and fixing it later.
When it's not important to block on, it doesn't get fixed.




-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Adam Williamson]

On Tue, 2016-11-15 at 11:57 -0500, Bill Nottingham wrote:
> Josh Boyer (jwbo...@fedoraproject.org) said: 
> > > If that is not the case anymore it would be good if that would be
> > > communicated in advance so that all users on mac hw could either
> > > switch distros or gang together to make a remix or something.
> > 
> > You are confusing Fedora with a company.  There is no top-down
> > communication on what is or is not supported.  There is no hardware
> > support list or hardware certification list.  It is literally what
> > people show up and test.
> 
> In the past couple of weeks we have:
> 
> 1) Fedora going out to survey HN about what they want, and 'seamless
> hardware compatiblity' being a top response
> 
> 2) This thread about how there's no institutional (for lack of a better
> word) project commitment to any set of supportable hardware in particular

Well, no, this thread is about how there's insufficient 'institutional'
commitment to working on Macs. The answer to 1) is almost certainly not
going to be 'focus on Fedora working well on Macs'. It may well be
'focus on Fedora working well on some specific hardware', but I'd be
extremely surprised if that that hardware turned out to be 'Macs'.

I would not be at all surprised to see a response to 1) be an effort to
define some specific hardware configurations that Workstation targets.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Adam Williamson]

On Tue, 2016-11-15 at 08:36 -0800, Chris Murphy wrote:
> On Mon, Nov 14, 2016 at 4:49 PM, Adam Williamson
>  wrote:
> > On Mon, 2016-11-14 at 14:30 -0800, Chris Murphy wrote:
> > > On Mon, Nov 14, 2016 at 1:26 PM, Josh Boyer  
> > > wrote:
> > > 
> > > > If the features were developed and tested during the creation of the
> > > > release, why would they fail criteria at the last minute?
> > > 
> > > Bit rot. That particular code is being modified, and there's no
> > > testing on hardware affected by those changes before they get pushed
> > > to the Fedora testing canary. This sort of relationship with an
> > > upstream is exactly the reason why people refer to Fedora as Red Hat's
> > > test bed.
> > > 
> > > There's also an imbalance in funding Anaconda churn which is mostly
> > > paid development, vs Fedora QA which no doubt has a much smaller
> > > budget and to date has largely depended on unpaid contributors for
> > > this testing.
> > 
> > BTW, you're acting under one fundamental misconception here: the change
> > that broke this was in *blivet*, not anaconda. Those development teams
> > are now quite significantly separate.
> 
> BTW, within the last couple of weeks you and I had a neat conversation
> that went something like this:
> cmurf: pretty sure this is a blivet bug, not anaconda
> adamw: meh, it's all one big team, they can sort it out and change the
> component if necessary
> cmurf: ok

> For future reference, wait at least five weeks for my short term
> memory recall to fade before playing this particular mind trick on me.

I think I'm playing a mind trick on myself ;) They're really not 'one
big team', that was inaccurate. It'd be better to say that they're used
to reassigning bugs from one to the other. But they actually do
function as separate teams with separate development plans now, albeit
of course they have to co-ordinate major blivet changes.

> But hey, in 1033778, a big part of its years long existence can be
> attributed to buck passing among the fiefdom of components. If there's
> a fundamental misconception, it's that users understand the 'get your
> bug off my lawn' mentality. These are Fedora bugs. That's the
> perception.

But we weren't discussing whose job it is to fix it, but rather your
theory that 'anaconda churn' is deleterious.

> > > There's seemingly no lack of resources for an installer that's in
> > > continuous development without any apparent improvement in usability
> > > or stability or blocker bugs since Fedora 17.
> > 
> > This is completely false. The stability of anaconda has *greatly*
> > improved since Fedora 17.
> 
> I did say apparent, although I should have been more clear by using
> "apparent to me" since it's based on my own bug reporting experience.
> Better qualified, even if it were true that I filed 50% fewer bugs for
> Fedora 25's installer, I think it's still excessive rather than
> greatly improved. In a decade I've experienced fewer bugs against all
> other installers combined, than the bugs I've filed against Fedora's
> in any single cycle.

It is entirely possible, of course, to be 'greatly improved' and still
'excessive'. You didn't argue that the installer is too buggy, you
argued that it hasn't got any less buggy ('stability or blocker bugs')
since Fedora 17. So now you're completely changing your premise.

Still, we've been round this goat rodeo many times, and I know you know
perfectly well why anaconda is susceptible to bugs: because it does a
lot of stuff. Have you considered how many bugs you'd find if you only
tested the same things in anaconda that you can actually *do at all* in
other distributions?

On this specific topic, though, I think there's a reasonable argument
to drop the clever-clever 'make Fedora show up in macOS's graphical
boot menu' trick if there is insufficient commitment to it on the
development side. It's a neat trick, but it does seem apparent that the
blivet change wasn't run by anyone who's familiar with it, which
suggests that either that needs to change or we need to dump it and
just treat Macs more like other UEFI systems, losing the graphical boot
menu trick but gaining some reliability.

> > I think before you keep up this line of argument you should provide
> > some concrete examples of the 'weird changes' and 'code churn' you are
> > claiming.
> 
> OK well the most obvious would be the four installer UIs in 5 years,
> should blivet-gui get integrated in Fedora 26. The old bottom UI is
> dumped (1), and replaced with automatic partitioning (2) and custom's
> top down UI (3). Then the idea becomes the top down UI isn't doing
> what users want so add a new bottom up UI (4).

Uh, that's some strange counting you've got there, bub. Your '1', '2'
and '3' are actually all the same single change: newUI. And oldUI still
effectively had a 'guided workflow' and a 'custom workflow'; they were
just presented slightly differently (linearly).
-- 
Adam 

Re: Fedora on Macs, removing the release criterion

[Bill Nottingham]

Josh Boyer (jwbo...@fedoraproject.org) said: 
> > If that is not the case anymore it would be good if that would be
> > communicated in advance so that all users on mac hw could either
> > switch distros or gang together to make a remix or something.
> 
> You are confusing Fedora with a company.  There is no top-down
> communication on what is or is not supported.  There is no hardware
> support list or hardware certification list.  It is literally what
> people show up and test.

In the past couple of weeks we have:

1) Fedora going out to survey HN about what they want, and 'seamless
hardware compatiblity' being a top response

2) This thread about how there's no institutional (for lack of a better
word) project commitment to any set of supportable hardware in particular

If #2 is the hard reality, there's not much point to even bothering with
the effort of inventorying items from surveys like #1.

If #1 is a serious effort, then that should lead to a discussion of how
we fix #2... but that's a discussion for a council or "please
$CORPORATE_SPONSOR, help us" list, rather than this tactical thread.

I do think that, for the sake of the project, the disconnect does
need to be resolved somehow.

Bill
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Chris Murphy]

On Mon, Nov 14, 2016 at 4:49 PM, Adam Williamson
 wrote:
> On Mon, 2016-11-14 at 14:30 -0800, Chris Murphy wrote:
>> On Mon, Nov 14, 2016 at 1:26 PM, Josh Boyer  
>> wrote:
>>
>> > If the features were developed and tested during the creation of the
>> > release, why would they fail criteria at the last minute?
>>
>> Bit rot. That particular code is being modified, and there's no
>> testing on hardware affected by those changes before they get pushed
>> to the Fedora testing canary. This sort of relationship with an
>> upstream is exactly the reason why people refer to Fedora as Red Hat's
>> test bed.
>>
>> There's also an imbalance in funding Anaconda churn which is mostly
>> paid development, vs Fedora QA which no doubt has a much smaller
>> budget and to date has largely depended on unpaid contributors for
>> this testing.
>
> BTW, you're acting under one fundamental misconception here: the change
> that broke this was in *blivet*, not anaconda. Those development teams
> are now quite significantly separate.

BTW, within the last couple of weeks you and I had a neat conversation
that went something like this:
cmurf: pretty sure this is a blivet bug, not anaconda
adamw: meh, it's all one big team, they can sort it out and change the
component if necessary
cmurf: ok

For future reference, wait at least five weeks for my short term
memory recall to fade before playing this particular mind trick on me.

But hey, in 1033778, a big part of its years long existence can be
attributed to buck passing among the fiefdom of components. If there's
a fundamental misconception, it's that users understand the 'get your
bug off my lawn' mentality. These are Fedora bugs. That's the
perception.


>> There's seemingly no lack of resources for an installer that's in
>> continuous development without any apparent improvement in usability
>> or stability or blocker bugs since Fedora 17.
>
> This is completely false. The stability of anaconda has *greatly*
> improved since Fedora 17.

I did say apparent, although I should have been more clear by using
"apparent to me" since it's based on my own bug reporting experience.
Better qualified, even if it were true that I filed 50% fewer bugs for
Fedora 25's installer, I think it's still excessive rather than
greatly improved. In a decade I've experienced fewer bugs against all
other installers combined, than the bugs I've filed against Fedora's
in any single cycle.



>> More canaries of any sort is not going to help find the source of the
>> problem and the solution. What's needed are people who can do the
>> proper kind of reporting, and there simply aren't enough of those to
>> keep up with all of OUR weird changes and code churn.
>
> I think before you keep up this line of argument you should provide
> some concrete examples of the 'weird changes' and 'code churn' you are
> claiming.

OK well the most obvious would be the four installer UIs in 5 years,
should blivet-gui get integrated in Fedora 26. The old bottom UI is
dumped (1), and replaced with automatic partitioning (2) and custom's
top down UI (3). Then the idea becomes the top down UI isn't doing
what users want so add a new bottom up UI (4). That's what I mean by
churn. And I think it's weird to be building yet another sky castle
before fixing data loss inducing bugs and  persistent sources of UI/Ux
confusion.

mactel-boot is clever and pretty, but it is weird because a.) it
causes Macs to be treated differently from other EFI systems and b.)
no other distro is using it c.) people don't understand it. It
increases the foot print for bugs and other confusion.



-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Adam Williamson]

On Tue, 2016-11-15 at 17:27 +0100, Andreas Tunek wrote:
> Maybe the release criteria should reflect that then. Right now it says
> that mac support is a criteria for release.

You do remember the topic of this thread, right?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Adam Williamson]

On Tue, 2016-11-15 at 17:15 +0100, Andreas Tunek wrote:
> 2016-11-15 8:43 GMT+01:00 Adam Williamson :
> > On Tue, 2016-11-15 at 07:35 +0100, Andreas Tunek wrote:
> > > If something is in the release criteria I expect the feature to be
> > > present in the release. If the feature in question has worked for ~20
> > > Fedora releases it is not my first priority to test, unless there is
> > > specific communication otherwise, like specific "Mac install testing
> > > days" (which to my knowledge there hasn't been).
> > 
> > As a general rule of thumb, stuff that gets tested keeps working. Stuff
> > that doesn't breaks. It's why we test stuff.
> > --
> 
> For me as a user it is really difficult to know what has been tested
> and what needs more testing. The test days are really good so you know
> what to focus on.

We haven't done an 'installer Test Day' for a while because it's not a
typical fit for a Test Day. Test Days are usually for testing out some
big new feature or major change in a release which is a kind of unitary
thing. We haven't had a single specific pinpointable 'major change' in
the installer for several releases now; rather its behaviour tends to
evolve gradually with smaller changes that land frequently, and changes
to the behaviour of other components it depends upon.

What we *do* have for the installer is release validation testing. We
announce all the release validation testing events to this list, and
the OSX test is listed right there. I have sent out pleas multiple
times this cycle for people to help test all the Alpha/Beta/Final
priority validation tests.

Did these not reach you, or is the process too difficult to follow?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Josh Boyer]

On Tue, Nov 15, 2016 at 11:27 AM, Andreas Tunek  wrote:
> 2016-11-15 17:12 GMT+01:00 Josh Boyer :
>> On Tue, Nov 15, 2016 at 11:06 AM, Andreas Tunek  
>> wrote:
>>> 2016-11-15 15:35 GMT+01:00 Stephen John Smoogen :
 On 15 November 2016 at 01:35, Andreas Tunek  
 wrote:
> 2016-11-15 1:06 GMT+01:00 Zbigniew Jędrzejewski-Szmek :

>> You seem to confuse something being in the release criteria, and
>> something being possible. But that's secondary. If you would like this
>> scenario to be supported, then commit to testing it before the next
>> release (in advance, at least a week before the beta freeze).
>>
>
> If something is in the release criteria I expect the feature to be
> present in the release. If the feature in question has worked for ~20
> Fedora releases it is not my first priority to test, unless there is
> specific communication otherwise, like specific "Mac install testing
> days" (which to my knowledge there hasn't been).

 You seem to be under a misapprehension on how distributions are
 built.. even ones which are paid for. In any distribution, if
 something is important then the stakeholders (the people who think it
 is important) make sure that it is funded so that the resources are
 there for testing. That funding in a corporate distribution is in
 paying for equipment, staff and hours to get that item tested and
 developed. In a 'free' distribution, that funding is volunteering the
 time to make sure it is tested. [And even in paid distributions, when
 things aren't paid for and people assume that X was going to be
 there.. if X isn't working on release day it comes back to the
 stakeholders that they needed not to assume it would be.]


>>>
>>> I was under the (mis?)assumption that, due to being in the release
>>> criteria, mac "support" was important for Fedora. It seems to have
>>> been that way for 10 years.
>>
>> It is as important as any other platform that the community wants to support.
>>
>>> If that is not the case anymore it would be good if that would be
>>> communicated in advance so that all users on mac hw could either
>>> switch distros or gang together to make a remix or something.
>>
>> You are confusing Fedora with a company.  There is no top-down
>> communication on what is or is not supported.  There is no hardware
>> support list or hardware certification list.  It is literally what
>> people show up and test.
>>
>
> Maybe the release criteria should reflect that then. Right now it says
> that mac support is a criteria for release.

That's exactly what some of us have been saying :).

>>> As a user and very occasional contributor (mostly of bug reports) it
>>> is very hard to know what is most important to test. AFAIK there
>>> wasn't any "Installer test day" or anything similar. So I and a lot of
>>> people probably tested other stuff*.
>>
>> As a user and contributor, it is important to test what YOU find
>> important.  If that is Macs, then test every aspect of Mac support
>> (install, runtime, etc).  If it doesn't work, report it.  If it does
>> and you want to move on to testing something else, do that.
>>
>> The cumulative efforts define what works and doesn't work in Fedora on
>> any given release.
>>
>
> As everyone else I have limited time and resources and lot of things a
> care about in an OS. It is unfortunately impossible for me to test
> everything.

Which is why I said to test things you really care about.

>>> If I would have paid for RHEL 8 and it did not work on hardware that
>>> RHEL 7.3 supported without any communication from Red Hat I would get
>>> pissed and most probably find another vendor.
>>
>> That's the primary difference between Fedora and RHEL.  RHEL is made
>> to support what people pay for and the Service Level Agreements
>> dictate what is and isn't supported.  Fedora is made by people that
>> want to see something work, and that thing working is entirely
>> contingent upon people showing up to make sure it does.
>>
>
> Yes and the people who showed up and did the work has made a release
> criteria. Do you want to change that?

No, but they need to realize it's not a one-time thing.  You don't do
the work and then disappear assuming it's going to continue to work
forever at the expense of someone else ensuring that.  It requires
sustained commitment.

josh
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Andreas Tunek]

2016-11-15 17:12 GMT+01:00 Josh Boyer :
> On Tue, Nov 15, 2016 at 11:06 AM, Andreas Tunek  
> wrote:
>> 2016-11-15 15:35 GMT+01:00 Stephen John Smoogen :
>>> On 15 November 2016 at 01:35, Andreas Tunek  wrote:
 2016-11-15 1:06 GMT+01:00 Zbigniew Jędrzejewski-Szmek :
>>>
> You seem to confuse something being in the release criteria, and
> something being possible. But that's secondary. If you would like this
> scenario to be supported, then commit to testing it before the next
> release (in advance, at least a week before the beta freeze).
>

 If something is in the release criteria I expect the feature to be
 present in the release. If the feature in question has worked for ~20
 Fedora releases it is not my first priority to test, unless there is
 specific communication otherwise, like specific "Mac install testing
 days" (which to my knowledge there hasn't been).
>>>
>>> You seem to be under a misapprehension on how distributions are
>>> built.. even ones which are paid for. In any distribution, if
>>> something is important then the stakeholders (the people who think it
>>> is important) make sure that it is funded so that the resources are
>>> there for testing. That funding in a corporate distribution is in
>>> paying for equipment, staff and hours to get that item tested and
>>> developed. In a 'free' distribution, that funding is volunteering the
>>> time to make sure it is tested. [And even in paid distributions, when
>>> things aren't paid for and people assume that X was going to be
>>> there.. if X isn't working on release day it comes back to the
>>> stakeholders that they needed not to assume it would be.]
>>>
>>>
>>
>> I was under the (mis?)assumption that, due to being in the release
>> criteria, mac "support" was important for Fedora. It seems to have
>> been that way for 10 years.
>
> It is as important as any other platform that the community wants to support.
>
>> If that is not the case anymore it would be good if that would be
>> communicated in advance so that all users on mac hw could either
>> switch distros or gang together to make a remix or something.
>
> You are confusing Fedora with a company.  There is no top-down
> communication on what is or is not supported.  There is no hardware
> support list or hardware certification list.  It is literally what
> people show up and test.
>

Maybe the release criteria should reflect that then. Right now it says
that mac support is a criteria for release.

>> As a user and very occasional contributor (mostly of bug reports) it
>> is very hard to know what is most important to test. AFAIK there
>> wasn't any "Installer test day" or anything similar. So I and a lot of
>> people probably tested other stuff*.
>
> As a user and contributor, it is important to test what YOU find
> important.  If that is Macs, then test every aspect of Mac support
> (install, runtime, etc).  If it doesn't work, report it.  If it does
> and you want to move on to testing something else, do that.
>
> The cumulative efforts define what works and doesn't work in Fedora on
> any given release.
>

As everyone else I have limited time and resources and lot of things a
care about in an OS. It is unfortunately impossible for me to test
everything.

>> If I would have paid for RHEL 8 and it did not work on hardware that
>> RHEL 7.3 supported without any communication from Red Hat I would get
>> pissed and most probably find another vendor.
>
> That's the primary difference between Fedora and RHEL.  RHEL is made
> to support what people pay for and the Service Level Agreements
> dictate what is and isn't supported.  Fedora is made by people that
> want to see something work, and that thing working is entirely
> contingent upon people showing up to make sure it does.
>

Yes and the people who showed up and did the work has made a release
criteria. Do you want to change that?

> josh
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Andreas Tunek]

2016-11-15 8:43 GMT+01:00 Adam Williamson :
> On Tue, 2016-11-15 at 07:35 +0100, Andreas Tunek wrote:
>> If something is in the release criteria I expect the feature to be
>> present in the release. If the feature in question has worked for ~20
>> Fedora releases it is not my first priority to test, unless there is
>> specific communication otherwise, like specific "Mac install testing
>> days" (which to my knowledge there hasn't been).
>
> As a general rule of thumb, stuff that gets tested keeps working. Stuff
> that doesn't breaks. It's why we test stuff.
> --

For me as a user it is really difficult to know what has been tested
and what needs more testing. The test days are really good so you know
what to focus on.

> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Josh Boyer]

On Tue, Nov 15, 2016 at 11:06 AM, Andreas Tunek  wrote:
> 2016-11-15 15:35 GMT+01:00 Stephen John Smoogen :
>> On 15 November 2016 at 01:35, Andreas Tunek  wrote:
>>> 2016-11-15 1:06 GMT+01:00 Zbigniew Jędrzejewski-Szmek :
>>
 You seem to confuse something being in the release criteria, and
 something being possible. But that's secondary. If you would like this
 scenario to be supported, then commit to testing it before the next
 release (in advance, at least a week before the beta freeze).

>>>
>>> If something is in the release criteria I expect the feature to be
>>> present in the release. If the feature in question has worked for ~20
>>> Fedora releases it is not my first priority to test, unless there is
>>> specific communication otherwise, like specific "Mac install testing
>>> days" (which to my knowledge there hasn't been).
>>
>> You seem to be under a misapprehension on how distributions are
>> built.. even ones which are paid for. In any distribution, if
>> something is important then the stakeholders (the people who think it
>> is important) make sure that it is funded so that the resources are
>> there for testing. That funding in a corporate distribution is in
>> paying for equipment, staff and hours to get that item tested and
>> developed. In a 'free' distribution, that funding is volunteering the
>> time to make sure it is tested. [And even in paid distributions, when
>> things aren't paid for and people assume that X was going to be
>> there.. if X isn't working on release day it comes back to the
>> stakeholders that they needed not to assume it would be.]
>>
>>
>
> I was under the (mis?)assumption that, due to being in the release
> criteria, mac "support" was important for Fedora. It seems to have
> been that way for 10 years.

It is as important as any other platform that the community wants to support.

> If that is not the case anymore it would be good if that would be
> communicated in advance so that all users on mac hw could either
> switch distros or gang together to make a remix or something.

You are confusing Fedora with a company.  There is no top-down
communication on what is or is not supported.  There is no hardware
support list or hardware certification list.  It is literally what
people show up and test.

> As a user and very occasional contributor (mostly of bug reports) it
> is very hard to know what is most important to test. AFAIK there
> wasn't any "Installer test day" or anything similar. So I and a lot of
> people probably tested other stuff*.

As a user and contributor, it is important to test what YOU find
important.  If that is Macs, then test every aspect of Mac support
(install, runtime, etc).  If it doesn't work, report it.  If it does
and you want to move on to testing something else, do that.

The cumulative efforts define what works and doesn't work in Fedora on
any given release.

> If I would have paid for RHEL 8 and it did not work on hardware that
> RHEL 7.3 supported without any communication from Red Hat I would get
> pissed and most probably find another vendor.

That's the primary difference between Fedora and RHEL.  RHEL is made
to support what people pay for and the Service Level Agreements
dictate what is and isn't supported.  Fedora is made by people that
want to see something work, and that thing working is entirely
contingent upon people showing up to make sure it does.

josh
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Andreas Tunek]

2016-11-15 13:45 GMT+01:00 Josh Boyer :
> On Mon, Nov 14, 2016 at 4:52 PM, Andreas Tunek  
> wrote:
>> 2016-11-14 22:26 GMT+01:00 Josh Boyer :
>>> On Mon, Nov 14, 2016 at 4:13 PM, Andreas Tunek  
>>> wrote:
 2016-11-14 14:01 GMT+01:00 Stephen Gallagher :
> On 11/13/2016 01:46 PM, Ms Sanchez wrote:
>>
>>
>> On 11/11/16 14:33, Stephen Gallagher wrote:
>>>
>>> Just to address this specifically, I am referring to Apple's penchant 
>>> for
>>> stuffing their machines with hardware from vendors that don't play well 
>>> with
>>> open-source (for example, switching to wifi-only devices and shipping 
>>> Broadcom
>>> chipsets with no open-source drivers). Then also playing games with 
>>> their
>>> bootloader system so that we have to go through lots of hoops to trick 
>>> it into
>>> letting us install.
>>>
>>> Apple's entire business model is predicated on the idea that they know 
>>> best and
>>> you should only ever run software on their devices that they have 
>>> provided to
>>> you... at a substantial percentage for themselves. They do whatever 
>>> they can at
>>> a technical level to enable this.
>>>
>>> (Note: I'm not attempting to vilify Apple here. Their devices are 
>>> usually
>>> sturdy, well-constructed and certainly attractive. They are however a 
>>> company
>>> trying to make money and they have a certain business model that is 
>>> largely
>>> dependent on *not* enabling us.)
>>>
>>>
>>
>> Apple's business model is based on selling you a golden cage.  They are 
>> entitled
>> to do that and we are entitled to dislike it.
>
> Certainly. My point is that I don't feel that we are necessarily 
> responsible for
> working around their antagonism either. Yes, it would be nice if Fedora
> supported all hardware ever made. But the simple truth is that Apple 
> tries very
> hard to make it *not* work. They have a vested interest in that.
>
> So I assert that while support for Apple hardware is desirable, I don't 
> believe
> that the lack of it should prevent us from shipping Fedora for all the 
> other
> hardware that we do support.
>
>

 If you stop supporting certain hardware right before release due to a
 regression bug you set a very troublesome precedent. It not only means
 that the work people did developing and testing the features where
 wasted, it also means that Fedora can toss out any feature at any time
 if there is a bug. And that is not a very stable OS to use and
 contribute to.
>>>
>>> If the features were developed and tested during the creation of the
>>> release, why would they fail criteria at the last minute?  You are
>>> making a good argument to not throw away something because "people
>>> don't like it", but in the context of this discussion there seems to
>>> be a distinct lack of resources actually doing the work.  It may be
>>> perfectly justifiable to do a release anyway under that premise.
>>>
>>
>> AFAIK, you have been able to install Fedora on Intel Macs since 2008
>> (that was when I first tried). To not be able to install Fedora on
>> (Intel) Macs is a regression.
>
> Yes.  Nobody is arguing that it isn't a bug.
>
>>> Also, there is a large difference between shipping a release that
>>> works on a majority of hardware with the goal of fixing it where it
>>> doesn't after, and "stop supporting certain hardware".
>>>
>>
>> How do you fix it if you can't install the release? Do you make a new
>> release with all the testing again (to make sure you do not have other
>> regression bugs)?
>
> Anaconda has updates.img, which might be usable post-release.  Barring
> that, there are the update respins that other community members do.
> Pretending those don't exist seems silly.
>
>>> Lastly, support is a very loaded word, particularly in the context of
>>> a community driven project.  We actually do not have an x86 equivalent
>>> of the ARM supported-boards list, so it's completely random as to what
>>> laptops and desktops are tested and prioritized.  That might be
>>> something to focus on going forward.
>>
>> It has been in the release critera that you should be able to install
>> on macs and it has worked for a very long time. If you are going to
>> remove that support you should really let people know in advance (not
>> a week before release).
>
> Again, nobody is saying "remove support".  We're saying "fix it later".
>

How do you "fix it later"? Would that be a new image?

>> Also, most hardware support is handled by Linux which has a much
>> bigger community than Fedora. But this issue seems to be in Anaconda
>> which is only used by Fedora (and derivatives?). Other OS installers
>> does not seem to have this 

Re: Fedora on Macs, removing the release criterion

[Andreas Tunek]

2016-11-15 15:35 GMT+01:00 Stephen John Smoogen :
> On 15 November 2016 at 01:35, Andreas Tunek  wrote:
>> 2016-11-15 1:06 GMT+01:00 Zbigniew Jędrzejewski-Szmek :
>
>>> You seem to confuse something being in the release criteria, and
>>> something being possible. But that's secondary. If you would like this
>>> scenario to be supported, then commit to testing it before the next
>>> release (in advance, at least a week before the beta freeze).
>>>
>>
>> If something is in the release criteria I expect the feature to be
>> present in the release. If the feature in question has worked for ~20
>> Fedora releases it is not my first priority to test, unless there is
>> specific communication otherwise, like specific "Mac install testing
>> days" (which to my knowledge there hasn't been).
>
> You seem to be under a misapprehension on how distributions are
> built.. even ones which are paid for. In any distribution, if
> something is important then the stakeholders (the people who think it
> is important) make sure that it is funded so that the resources are
> there for testing. That funding in a corporate distribution is in
> paying for equipment, staff and hours to get that item tested and
> developed. In a 'free' distribution, that funding is volunteering the
> time to make sure it is tested. [And even in paid distributions, when
> things aren't paid for and people assume that X was going to be
> there.. if X isn't working on release day it comes back to the
> stakeholders that they needed not to assume it would be.]
>
>

I was under the (mis?)assumption that, due to being in the release
criteria, mac "support" was important for Fedora. It seems to have
been that way for 10 years.

If that is not the case anymore it would be good if that would be
communicated in advance so that all users on mac hw could either
switch distros or gang together to make a remix or something.

As a user and very occasional contributor (mostly of bug reports) it
is very hard to know what is most important to test. AFAIK there
wasn't any "Installer test day" or anything similar. So I and a lot of
people probably tested other stuff*.

If I would have paid for RHEL 8 and it did not work on hardware that
RHEL 7.3 supported without any communication from Red Hat I would get
pissed and most probably find another vendor.

/Andreas


*I haven't made any bug report for F25 because all issues I found had
already been reported.

>
>
>
> --
> Stephen J Smoogen.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Stephen John Smoogen]

On 15 November 2016 at 01:35, Andreas Tunek  wrote:
> 2016-11-15 1:06 GMT+01:00 Zbigniew Jędrzejewski-Szmek :

>> You seem to confuse something being in the release criteria, and
>> something being possible. But that's secondary. If you would like this
>> scenario to be supported, then commit to testing it before the next
>> release (in advance, at least a week before the beta freeze).
>>
>
> If something is in the release criteria I expect the feature to be
> present in the release. If the feature in question has worked for ~20
> Fedora releases it is not my first priority to test, unless there is
> specific communication otherwise, like specific "Mac install testing
> days" (which to my knowledge there hasn't been).

You seem to be under a misapprehension on how distributions are
built.. even ones which are paid for. In any distribution, if
something is important then the stakeholders (the people who think it
is important) make sure that it is funded so that the resources are
there for testing. That funding in a corporate distribution is in
paying for equipment, staff and hours to get that item tested and
developed. In a 'free' distribution, that funding is volunteering the
time to make sure it is tested. [And even in paid distributions, when
things aren't paid for and people assume that X was going to be
there.. if X isn't working on release day it comes back to the
stakeholders that they needed not to assume it would be.]





-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Josh Boyer]

On Tue, Nov 15, 2016 at 8:08 AM, Peter Robinson  wrote:
 Just to address this specifically, I am referring to Apple's penchant 
 for
 stuffing their machines with hardware from vendors that don't play 
 well with
 open-source (for example, switching to wifi-only devices and shipping 
 Broadcom
 chipsets with no open-source drivers). Then also playing games with 
 their
 bootloader system so that we have to go through lots of hoops to trick 
 it into
 letting us install.

 Apple's entire business model is predicated on the idea that they know 
 best and
 you should only ever run software on their devices that they have 
 provided to
 you... at a substantial percentage for themselves. They do whatever 
 they can at
 a technical level to enable this.

 (Note: I'm not attempting to vilify Apple here. Their devices are 
 usually
 sturdy, well-constructed and certainly attractive. They are however a 
 company
 trying to make money and they have a certain business model that is 
 largely
 dependent on *not* enabling us.)


>>>
>>> Apple's business model is based on selling you a golden cage.  They are 
>>> entitled
>>> to do that and we are entitled to dislike it.
>>
>> Certainly. My point is that I don't feel that we are necessarily 
>> responsible for
>> working around their antagonism either. Yes, it would be nice if Fedora
>> supported all hardware ever made. But the simple truth is that Apple 
>> tries very
>> hard to make it *not* work. They have a vested interest in that.
>>
>> So I assert that while support for Apple hardware is desirable, I don't 
>> believe
>> that the lack of it should prevent us from shipping Fedora for all the 
>> other
>> hardware that we do support.
>>
>>
>
> If you stop supporting certain hardware right before release due to a
> regression bug you set a very troublesome precedent. It not only means
> that the work people did developing and testing the features where
> wasted, it also means that Fedora can toss out any feature at any time
> if there is a bug. And that is not a very stable OS to use and
> contribute to.

 If the features were developed and tested during the creation of the
 release, why would they fail criteria at the last minute?  You are
 making a good argument to not throw away something because "people
 don't like it", but in the context of this discussion there seems to
 be a distinct lack of resources actually doing the work.  It may be
 perfectly justifiable to do a release anyway under that premise.

>>>
>>> AFAIK, you have been able to install Fedora on Intel Macs since 2008
>>> (that was when I first tried). To not be able to install Fedora on
>>> (Intel) Macs is a regression.
>>
>> Yes.  Nobody is arguing that it isn't a bug.
>>
 Also, there is a large difference between shipping a release that
 works on a majority of hardware with the goal of fixing it where it
 doesn't after, and "stop supporting certain hardware".

>>>
>>> How do you fix it if you can't install the release? Do you make a new
>>> release with all the testing again (to make sure you do not have other
>>> regression bugs)?
>>
>> Anaconda has updates.img, which might be usable post-release.  Barring
>> that, there are the update respins that other community members do.
>> Pretending those don't exist seems silly.
>
> Well to the average user they don't exist. They got to getfedora.org
> and download the image there, it doesn't work, they go and get another
> distro that does work and move on with life.

If we're going to reduce arguments to absurd simplicity, then to the
average Mac user Fedora doesn't exist and this isn't a problem.

Look, we have resources.  If we need to leverage them, we can.  Which
means we can modify websites.  Let's not pretend we don't control what
we display on our own infrastructure.

josh
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Peter Robinson]

>>> Just to address this specifically, I am referring to Apple's penchant 
>>> for
>>> stuffing their machines with hardware from vendors that don't play well 
>>> with
>>> open-source (for example, switching to wifi-only devices and shipping 
>>> Broadcom
>>> chipsets with no open-source drivers). Then also playing games with 
>>> their
>>> bootloader system so that we have to go through lots of hoops to trick 
>>> it into
>>> letting us install.
>>>
>>> Apple's entire business model is predicated on the idea that they know 
>>> best and
>>> you should only ever run software on their devices that they have 
>>> provided to
>>> you... at a substantial percentage for themselves. They do whatever 
>>> they can at
>>> a technical level to enable this.
>>>
>>> (Note: I'm not attempting to vilify Apple here. Their devices are 
>>> usually
>>> sturdy, well-constructed and certainly attractive. They are however a 
>>> company
>>> trying to make money and they have a certain business model that is 
>>> largely
>>> dependent on *not* enabling us.)
>>>
>>>
>>
>> Apple's business model is based on selling you a golden cage.  They are 
>> entitled
>> to do that and we are entitled to dislike it.
>
> Certainly. My point is that I don't feel that we are necessarily 
> responsible for
> working around their antagonism either. Yes, it would be nice if Fedora
> supported all hardware ever made. But the simple truth is that Apple 
> tries very
> hard to make it *not* work. They have a vested interest in that.
>
> So I assert that while support for Apple hardware is desirable, I don't 
> believe
> that the lack of it should prevent us from shipping Fedora for all the 
> other
> hardware that we do support.
>
>

 If you stop supporting certain hardware right before release due to a
 regression bug you set a very troublesome precedent. It not only means
 that the work people did developing and testing the features where
 wasted, it also means that Fedora can toss out any feature at any time
 if there is a bug. And that is not a very stable OS to use and
 contribute to.
>>>
>>> If the features were developed and tested during the creation of the
>>> release, why would they fail criteria at the last minute?  You are
>>> making a good argument to not throw away something because "people
>>> don't like it", but in the context of this discussion there seems to
>>> be a distinct lack of resources actually doing the work.  It may be
>>> perfectly justifiable to do a release anyway under that premise.
>>>
>>
>> AFAIK, you have been able to install Fedora on Intel Macs since 2008
>> (that was when I first tried). To not be able to install Fedora on
>> (Intel) Macs is a regression.
>
> Yes.  Nobody is arguing that it isn't a bug.
>
>>> Also, there is a large difference between shipping a release that
>>> works on a majority of hardware with the goal of fixing it where it
>>> doesn't after, and "stop supporting certain hardware".
>>>
>>
>> How do you fix it if you can't install the release? Do you make a new
>> release with all the testing again (to make sure you do not have other
>> regression bugs)?
>
> Anaconda has updates.img, which might be usable post-release.  Barring
> that, there are the update respins that other community members do.
> Pretending those don't exist seems silly.

Well to the average user they don't exist. They got to getfedora.org
and download the image there, it doesn't work, they go and get another
distro that does work and move on with life.

>>> Lastly, support is a very loaded word, particularly in the context of
>>> a community driven project.  We actually do not have an x86 equivalent
>>> of the ARM supported-boards list, so it's completely random as to what
>>> laptops and desktops are tested and prioritized.  That might be
>>> something to focus on going forward.
>>
>> It has been in the release critera that you should be able to install
>> on macs and it has worked for a very long time. If you are going to
>> remove that support you should really let people know in advance (not
>> a week before release).
>
> Again, nobody is saying "remove support".  We're saying "fix it later".
>
>> Also, most hardware support is handled by Linux which has a much
>> bigger community than Fedora. But this issue seems to be in Anaconda
>> which is only used by Fedora (and derivatives?). Other OS installers
>> does not seem to have this problem (AFAIK).
>
> OK?
>
> josh
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Josh Boyer]

On Mon, Nov 14, 2016 at 4:52 PM, Andreas Tunek  wrote:
> 2016-11-14 22:26 GMT+01:00 Josh Boyer :
>> On Mon, Nov 14, 2016 at 4:13 PM, Andreas Tunek  
>> wrote:
>>> 2016-11-14 14:01 GMT+01:00 Stephen Gallagher :
 On 11/13/2016 01:46 PM, Ms Sanchez wrote:
>
>
> On 11/11/16 14:33, Stephen Gallagher wrote:
>>
>> Just to address this specifically, I am referring to Apple's penchant for
>> stuffing their machines with hardware from vendors that don't play well 
>> with
>> open-source (for example, switching to wifi-only devices and shipping 
>> Broadcom
>> chipsets with no open-source drivers). Then also playing games with their
>> bootloader system so that we have to go through lots of hoops to trick 
>> it into
>> letting us install.
>>
>> Apple's entire business model is predicated on the idea that they know 
>> best and
>> you should only ever run software on their devices that they have 
>> provided to
>> you... at a substantial percentage for themselves. They do whatever they 
>> can at
>> a technical level to enable this.
>>
>> (Note: I'm not attempting to vilify Apple here. Their devices are usually
>> sturdy, well-constructed and certainly attractive. They are however a 
>> company
>> trying to make money and they have a certain business model that is 
>> largely
>> dependent on *not* enabling us.)
>>
>>
>
> Apple's business model is based on selling you a golden cage.  They are 
> entitled
> to do that and we are entitled to dislike it.

 Certainly. My point is that I don't feel that we are necessarily 
 responsible for
 working around their antagonism either. Yes, it would be nice if Fedora
 supported all hardware ever made. But the simple truth is that Apple tries 
 very
 hard to make it *not* work. They have a vested interest in that.

 So I assert that while support for Apple hardware is desirable, I don't 
 believe
 that the lack of it should prevent us from shipping Fedora for all the 
 other
 hardware that we do support.


>>>
>>> If you stop supporting certain hardware right before release due to a
>>> regression bug you set a very troublesome precedent. It not only means
>>> that the work people did developing and testing the features where
>>> wasted, it also means that Fedora can toss out any feature at any time
>>> if there is a bug. And that is not a very stable OS to use and
>>> contribute to.
>>
>> If the features were developed and tested during the creation of the
>> release, why would they fail criteria at the last minute?  You are
>> making a good argument to not throw away something because "people
>> don't like it", but in the context of this discussion there seems to
>> be a distinct lack of resources actually doing the work.  It may be
>> perfectly justifiable to do a release anyway under that premise.
>>
>
> AFAIK, you have been able to install Fedora on Intel Macs since 2008
> (that was when I first tried). To not be able to install Fedora on
> (Intel) Macs is a regression.

Yes.  Nobody is arguing that it isn't a bug.

>> Also, there is a large difference between shipping a release that
>> works on a majority of hardware with the goal of fixing it where it
>> doesn't after, and "stop supporting certain hardware".
>>
>
> How do you fix it if you can't install the release? Do you make a new
> release with all the testing again (to make sure you do not have other
> regression bugs)?

Anaconda has updates.img, which might be usable post-release.  Barring
that, there are the update respins that other community members do.
Pretending those don't exist seems silly.

>> Lastly, support is a very loaded word, particularly in the context of
>> a community driven project.  We actually do not have an x86 equivalent
>> of the ARM supported-boards list, so it's completely random as to what
>> laptops and desktops are tested and prioritized.  That might be
>> something to focus on going forward.
>
> It has been in the release critera that you should be able to install
> on macs and it has worked for a very long time. If you are going to
> remove that support you should really let people know in advance (not
> a week before release).

Again, nobody is saying "remove support".  We're saying "fix it later".

> Also, most hardware support is handled by Linux which has a much
> bigger community than Fedora. But this issue seems to be in Anaconda
> which is only used by Fedora (and derivatives?). Other OS installers
> does not seem to have this problem (AFAIK).

OK?

josh
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Adam Williamson]

On Tue, 2016-11-15 at 07:35 +0100, Andreas Tunek wrote:
> If something is in the release criteria I expect the feature to be
> present in the release. If the feature in question has worked for ~20
> Fedora releases it is not my first priority to test, unless there is
> specific communication otherwise, like specific "Mac install testing
> days" (which to my knowledge there hasn't been).

As a general rule of thumb, stuff that gets tested keeps working. Stuff
that doesn't breaks. It's why we test stuff.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Andreas Tunek]

2016-11-15 1:06 GMT+01:00 Zbigniew Jędrzejewski-Szmek :
> On Mon, Nov 14, 2016 at 10:52:15PM +0100, Andreas Tunek wrote:
>> AFAIK, you have been able to install Fedora on Intel Macs since 2008
>> (that was when I first tried). To not be able to install Fedora on
>> (Intel) Macs is a regression.
>>
>> > Also, there is a large difference between shipping a release that
>> > works on a majority of hardware with the goal of fixing it where it
>> > doesn't after, and "stop supporting certain hardware".
>> >
>>
>> How do you fix it if you can't install the release? Do you make a new
>> release with all the testing again (to make sure you do not have other
>> regression bugs)?
>>
>> > Lastly, support is a very loaded word, particularly in the context of
>> > a community driven project.  We actually do not have an x86 equivalent
>> > of the ARM supported-boards list, so it's completely random as to what
>> > laptops and desktops are tested and prioritized.  That might be
>> > something to focus on going forward.
>>
>> It has been in the release critera that you should be able to install
>> on macs and it has worked for a very long time. If you are going to
>> remove that support you should really let people know in advance (not
>> a week before release).
>
> You seem to confuse something being in the release criteria, and
> something being possible. But that's secondary. If you would like this
> scenario to be supported, then commit to testing it before the next
> release (in advance, at least a week before the beta freeze).
>

If something is in the release criteria I expect the feature to be
present in the release. If the feature in question has worked for ~20
Fedora releases it is not my first priority to test, unless there is
specific communication otherwise, like specific "Mac install testing
days" (which to my knowledge there hasn't been).

/Andreas

> Zbyszek
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Adam Williamson]

On Mon, 2016-11-14 at 14:30 -0800, Chris Murphy wrote:
> On Mon, Nov 14, 2016 at 1:26 PM, Josh Boyer  wrote:
> 
> > If the features were developed and tested during the creation of the
> > release, why would they fail criteria at the last minute?
> 
> Bit rot. That particular code is being modified, and there's no
> testing on hardware affected by those changes before they get pushed
> to the Fedora testing canary. This sort of relationship with an
> upstream is exactly the reason why people refer to Fedora as Red Hat's
> test bed.
> 
> There's also an imbalance in funding Anaconda churn which is mostly
> paid development, vs Fedora QA which no doubt has a much smaller
> budget and to date has largely depended on unpaid contributors for
> this testing.

BTW, you're acting under one fundamental misconception here: the change
that broke this was in *blivet*, not anaconda. Those development teams
are now quite significantly separate.

It was also a perfectly sensible and good change which led to
substantially clearer and more testable code; it was just an
unfortunate human error that an important condition was missed in the
refactor, and the tests didn't catch it. Humans err. It happens.

> There's seemingly no lack of resources for an installer that's in
> continuous development without any apparent improvement in usability
> or stability or blocker bugs since Fedora 17.

This is completely false. The stability of anaconda has *greatly*
improved since Fedora 17.

I think you're also substantially overestimating the actual amount of
change that happens in anaconda (never mind the confusion with blivet).
There's quite a lot less than there used to be.

> More canaries of any sort is not going to help find the source of the
> problem and the solution. What's needed are people who can do the
> proper kind of reporting, and there simply aren't enough of those to
> keep up with all of OUR weird changes and code churn.

I think before you keep up this line of argument you should provide
some concrete examples of the 'weird changes' and 'code churn' you are
claiming.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Zbigniew Jędrzejewski-Szmek]

On Mon, Nov 14, 2016 at 10:52:15PM +0100, Andreas Tunek wrote:
> AFAIK, you have been able to install Fedora on Intel Macs since 2008
> (that was when I first tried). To not be able to install Fedora on
> (Intel) Macs is a regression.
> 
> > Also, there is a large difference between shipping a release that
> > works on a majority of hardware with the goal of fixing it where it
> > doesn't after, and "stop supporting certain hardware".
> >
> 
> How do you fix it if you can't install the release? Do you make a new
> release with all the testing again (to make sure you do not have other
> regression bugs)?
> 
> > Lastly, support is a very loaded word, particularly in the context of
> > a community driven project.  We actually do not have an x86 equivalent
> > of the ARM supported-boards list, so it's completely random as to what
> > laptops and desktops are tested and prioritized.  That might be
> > something to focus on going forward.
> 
> It has been in the release critera that you should be able to install
> on macs and it has worked for a very long time. If you are going to
> remove that support you should really let people know in advance (not
> a week before release).

You seem to confuse something being in the release criteria, and
something being possible. But that's secondary. If you would like this
scenario to be supported, then commit to testing it before the next
release (in advance, at least a week before the beta freeze).

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Chris Murphy]

On Mon, Nov 14, 2016 at 1:26 PM, Josh Boyer  wrote:

> If the features were developed and tested during the creation of the
> release, why would they fail criteria at the last minute?

Bit rot. That particular code is being modified, and there's no
testing on hardware affected by those changes before they get pushed
to the Fedora testing canary. This sort of relationship with an
upstream is exactly the reason why people refer to Fedora as Red Hat's
test bed.

There's also an imbalance in funding Anaconda churn which is mostly
paid development, vs Fedora QA which no doubt has a much smaller
budget and to date has largely depended on unpaid contributors for
this testing.


>  You are
> making a good argument to not throw away something because "people
> don't like it", but in the context of this discussion there seems to
> be a distinct lack of resources actually doing the work.  It may be
> perfectly justifiable to do a release anyway under that premise.

There's seemingly no lack of resources for an installer that's in
continuous development without any apparent improvement in usability
or stability or blocker bugs since Fedora 17.


> Also, there is a large difference between shipping a release that
> works on a majority of hardware with the goal of fixing it where it
> doesn't after, and "stop supporting certain hardware".

This particular bug means Fedora ships uninstallable on Macs. There is
no fixing it after shipping; it means trying again with the next
release.


> Lastly, support is a very loaded word, particularly in the context of
> a community driven project.  We actually do not have an x86 equivalent
> of the ARM supported-boards list, so it's completely random as to what
> laptops and desktops are tested and prioritized.  That might be
> something to focus on going forward.

On the user list, forums, ask fedora, and bugzilla, there are quite a
large number of Windows users who have dual boot installation failures
right now too. And those bug reports lack any sufficient detail to
find out why the installation didn't work. Just today I got a
notification of yet another Windows 10 user who can't boot Windows 10
after installing Fedora.

More canaries of any sort is not going to help find the source of the
problem and the solution. What's needed are people who can do the
proper kind of reporting, and there simply aren't enough of those to
keep up with all of OUR weird changes and code churn.


-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Andreas Tunek]

2016-11-14 22:57 GMT+01:00 Adam Williamson :
> On Mon, 2016-11-14 at 22:13 +0100, Andreas Tunek wrote:
>> It not only means
>> that the work people did developing and testing the features where
>> wasted
>
> The change in question clearly was *not* tested as regards OS X,
> because the logic is very clearly broken and could not possibly have
> worked properly for any fresh dual boot install to a disk already
> containing OS X.

Well, somebody tested on a Mac with macOS/OS X, otherwise we wouldn't
be having this conversation and the release with "broken" mac support
would have been released.

But I think you do some selective quoting here. What I tried to convey
was that the effort of a lot of people during many years to be able to
install on macs would be discarded just because of one regression bug.
If you are going to remove functionality/hardware support you should
at least announce it someway otherwise people (users and contributors)
will lose faith in your project.

> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
> http://www.happyassassin.net
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Adam Williamson]

On Mon, 2016-11-14 at 22:13 +0100, Andreas Tunek wrote:
> It not only means
> that the work people did developing and testing the features where
> wasted

The change in question clearly was *not* tested as regards OS X,
because the logic is very clearly broken and could not possibly have
worked properly for any fresh dual boot install to a disk already
containing OS X.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Andreas Tunek]

2016-11-14 22:26 GMT+01:00 Josh Boyer :
> On Mon, Nov 14, 2016 at 4:13 PM, Andreas Tunek  
> wrote:
>> 2016-11-14 14:01 GMT+01:00 Stephen Gallagher :
>>> On 11/13/2016 01:46 PM, Ms Sanchez wrote:


 On 11/11/16 14:33, Stephen Gallagher wrote:
>
> Just to address this specifically, I am referring to Apple's penchant for
> stuffing their machines with hardware from vendors that don't play well 
> with
> open-source (for example, switching to wifi-only devices and shipping 
> Broadcom
> chipsets with no open-source drivers). Then also playing games with their
> bootloader system so that we have to go through lots of hoops to trick it 
> into
> letting us install.
>
> Apple's entire business model is predicated on the idea that they know 
> best and
> you should only ever run software on their devices that they have 
> provided to
> you... at a substantial percentage for themselves. They do whatever they 
> can at
> a technical level to enable this.
>
> (Note: I'm not attempting to vilify Apple here. Their devices are usually
> sturdy, well-constructed and certainly attractive. They are however a 
> company
> trying to make money and they have a certain business model that is 
> largely
> dependent on *not* enabling us.)
>
>

 Apple's business model is based on selling you a golden cage.  They are 
 entitled
 to do that and we are entitled to dislike it.
>>>
>>> Certainly. My point is that I don't feel that we are necessarily 
>>> responsible for
>>> working around their antagonism either. Yes, it would be nice if Fedora
>>> supported all hardware ever made. But the simple truth is that Apple tries 
>>> very
>>> hard to make it *not* work. They have a vested interest in that.
>>>
>>> So I assert that while support for Apple hardware is desirable, I don't 
>>> believe
>>> that the lack of it should prevent us from shipping Fedora for all the other
>>> hardware that we do support.
>>>
>>>
>>
>> If you stop supporting certain hardware right before release due to a
>> regression bug you set a very troublesome precedent. It not only means
>> that the work people did developing and testing the features where
>> wasted, it also means that Fedora can toss out any feature at any time
>> if there is a bug. And that is not a very stable OS to use and
>> contribute to.
>
> If the features were developed and tested during the creation of the
> release, why would they fail criteria at the last minute?  You are
> making a good argument to not throw away something because "people
> don't like it", but in the context of this discussion there seems to
> be a distinct lack of resources actually doing the work.  It may be
> perfectly justifiable to do a release anyway under that premise.
>

AFAIK, you have been able to install Fedora on Intel Macs since 2008
(that was when I first tried). To not be able to install Fedora on
(Intel) Macs is a regression.

> Also, there is a large difference between shipping a release that
> works on a majority of hardware with the goal of fixing it where it
> doesn't after, and "stop supporting certain hardware".
>

How do you fix it if you can't install the release? Do you make a new
release with all the testing again (to make sure you do not have other
regression bugs)?

> Lastly, support is a very loaded word, particularly in the context of
> a community driven project.  We actually do not have an x86 equivalent
> of the ARM supported-boards list, so it's completely random as to what
> laptops and desktops are tested and prioritized.  That might be
> something to focus on going forward.

It has been in the release critera that you should be able to install
on macs and it has worked for a very long time. If you are going to
remove that support you should really let people know in advance (not
a week before release).

Also, most hardware support is handled by Linux which has a much
bigger community than Fedora. But this issue seems to be in Anaconda
which is only used by Fedora (and derivatives?). Other OS installers
does not seem to have this problem (AFAIK).

/Andreas

>
> josh
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Josh Boyer]

On Mon, Nov 14, 2016 at 4:13 PM, Andreas Tunek  wrote:
> 2016-11-14 14:01 GMT+01:00 Stephen Gallagher :
>> On 11/13/2016 01:46 PM, Ms Sanchez wrote:
>>>
>>>
>>> On 11/11/16 14:33, Stephen Gallagher wrote:

 Just to address this specifically, I am referring to Apple's penchant for
 stuffing their machines with hardware from vendors that don't play well 
 with
 open-source (for example, switching to wifi-only devices and shipping 
 Broadcom
 chipsets with no open-source drivers). Then also playing games with their
 bootloader system so that we have to go through lots of hoops to trick it 
 into
 letting us install.

 Apple's entire business model is predicated on the idea that they know 
 best and
 you should only ever run software on their devices that they have provided 
 to
 you... at a substantial percentage for themselves. They do whatever they 
 can at
 a technical level to enable this.

 (Note: I'm not attempting to vilify Apple here. Their devices are usually
 sturdy, well-constructed and certainly attractive. They are however a 
 company
 trying to make money and they have a certain business model that is largely
 dependent on *not* enabling us.)


>>>
>>> Apple's business model is based on selling you a golden cage.  They are 
>>> entitled
>>> to do that and we are entitled to dislike it.
>>
>> Certainly. My point is that I don't feel that we are necessarily responsible 
>> for
>> working around their antagonism either. Yes, it would be nice if Fedora
>> supported all hardware ever made. But the simple truth is that Apple tries 
>> very
>> hard to make it *not* work. They have a vested interest in that.
>>
>> So I assert that while support for Apple hardware is desirable, I don't 
>> believe
>> that the lack of it should prevent us from shipping Fedora for all the other
>> hardware that we do support.
>>
>>
>
> If you stop supporting certain hardware right before release due to a
> regression bug you set a very troublesome precedent. It not only means
> that the work people did developing and testing the features where
> wasted, it also means that Fedora can toss out any feature at any time
> if there is a bug. And that is not a very stable OS to use and
> contribute to.

If the features were developed and tested during the creation of the
release, why would they fail criteria at the last minute?  You are
making a good argument to not throw away something because "people
don't like it", but in the context of this discussion there seems to
be a distinct lack of resources actually doing the work.  It may be
perfectly justifiable to do a release anyway under that premise.

Also, there is a large difference between shipping a release that
works on a majority of hardware with the goal of fixing it where it
doesn't after, and "stop supporting certain hardware".

Lastly, support is a very loaded word, particularly in the context of
a community driven project.  We actually do not have an x86 equivalent
of the ARM supported-boards list, so it's completely random as to what
laptops and desktops are tested and prioritized.  That might be
something to focus on going forward.

josh
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Andreas Tunek]

2016-11-14 14:01 GMT+01:00 Stephen Gallagher :
> On 11/13/2016 01:46 PM, Ms Sanchez wrote:
>>
>>
>> On 11/11/16 14:33, Stephen Gallagher wrote:
>>>
>>> Just to address this specifically, I am referring to Apple's penchant for
>>> stuffing their machines with hardware from vendors that don't play well with
>>> open-source (for example, switching to wifi-only devices and shipping 
>>> Broadcom
>>> chipsets with no open-source drivers). Then also playing games with their
>>> bootloader system so that we have to go through lots of hoops to trick it 
>>> into
>>> letting us install.
>>>
>>> Apple's entire business model is predicated on the idea that they know best 
>>> and
>>> you should only ever run software on their devices that they have provided 
>>> to
>>> you... at a substantial percentage for themselves. They do whatever they 
>>> can at
>>> a technical level to enable this.
>>>
>>> (Note: I'm not attempting to vilify Apple here. Their devices are usually
>>> sturdy, well-constructed and certainly attractive. They are however a 
>>> company
>>> trying to make money and they have a certain business model that is largely
>>> dependent on *not* enabling us.)
>>>
>>>
>>
>> Apple's business model is based on selling you a golden cage.  They are 
>> entitled
>> to do that and we are entitled to dislike it.
>
> Certainly. My point is that I don't feel that we are necessarily responsible 
> for
> working around their antagonism either. Yes, it would be nice if Fedora
> supported all hardware ever made. But the simple truth is that Apple tries 
> very
> hard to make it *not* work. They have a vested interest in that.
>
> So I assert that while support for Apple hardware is desirable, I don't 
> believe
> that the lack of it should prevent us from shipping Fedora for all the other
> hardware that we do support.
>
>

If you stop supporting certain hardware right before release due to a
regression bug you set a very troublesome precedent. It not only means
that the work people did developing and testing the features where
wasted, it also means that Fedora can toss out any feature at any time
if there is a bug. And that is not a very stable OS to use and
contribute to.

>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Fabio Alessandro Locati]

On Mon, Nov 14, 2016 at 08:01:07AM -0500, Stephen Gallagher wrote:
> So I assert that while support for Apple hardware is desirable, I don't 
> believe
> that the lack of it should prevent us from shipping Fedora for all the other
> hardware that we do support.

Hi,

That is exactly what I was trying to say few messages ago, but worded in
a much better way :).

Best,
Fale
-- 
Fabio Alessandro Locati
Red Hat - Senior Consultant

PGP Fingerprint: E815 3C49 2A8D FD8B 1CBD  BC85 FDB3 DF20 B2DC 9C1B


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Adam Williamson]

On Mon, 2016-11-14 at 12:06 -0500, Przemek Klosowski wrote:
> On 11/10/2016 10:09 PM, Adam Williamson wrote:
> > FWIW, I did not really get the sense at all that people were voting
> > for
> >  it as a blocker purely on the grounds that "we can get a fix in at
> > the
> > last minute". A one week slip might feel short to you, I dunno, but
> > I
> > think most release process people think it's a really long time and
> > hate it (hence the pressure to 'hero' sometimes). Having a *whole
> > week*
> > to fix a blocker and respin and test, frankly, feels like quite a
> > lot
> > of time, in a Fedora context.
> 
> If there's a consensus that issues are small enough so that the slip
> can be shorter, perhaps it'd be appropriate to consider something
> between the all-nighter 'hero-ing' and full week slip? Specifically,
> you guys make a technical decision that a known fix, respin and test
> will take two days, so you just postpone the release by that time,
> unless that specific process does not go as expected? 

The problem with that is that various other parts of the release
process are expected to occur on specific days of the week.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Stephen John Smoogen]

On 14 November 2016 at 12:06, Przemek Klosowski
 wrote:
> On 11/10/2016 10:09 PM, Adam Williamson wrote:
>
> FWIW, I did not really get the sense at all that people were voting for
>  it as a blocker purely on the grounds that "we can get a fix in at the
> last minute". A one week slip might feel short to you, I dunno, but I
> think most release process people think it's a really long time and
> hate it (hence the pressure to 'hero' sometimes). Having a *whole week*
> to fix a blocker and respin and test, frankly, feels like quite a lot
> of time, in a Fedora context.
>
> If there's a consensus that issues are small enough so that the slip can be
> shorter, perhaps it'd be appropriate to consider something between the
> all-nighter 'hero-ing' and full week slip? Specifically, you guys make a
> technical decision that a known fix, respin and test will take two days, so
> you just postpone the release by that time, unless that specific process
> does not go as expected?

Not really. There are multiple amounts of stuff that has to get done
to get a release out the door with a lot of it in human relations: let
the mirrors know, let the various news groups know, field questions
from press, get usergroups ready. Trying to move it later in the week
from the Tuesdays screws up a lot of people's set timelines.

>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>



-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Przemek Klosowski]

On 11/10/2016 10:09 PM, Adam Williamson wrote:

FWIW, I did not really get the sense at all that people were voting for
  it as a blocker purely on the grounds that "we can get a fix in at the
last minute". A one week slip might feel short to you, I dunno, but I
think most release process people think it's a really long time and
hate it (hence the pressure to 'hero' sometimes). Having a*whole week*
to fix a blocker and respin and test, frankly, feels like quite a lot
of time, in a Fedora context.


If there's a consensus that issues are small enough so that the slip can 
be shorter, perhaps it'd be appropriate to consider something between 
the all-nighter 'hero-ing' and full week slip? Specifically, you guys 
make a technical decision that a known fix, respin and test will take 
two days, so you just postpone the release by that time, unless that 
specific process does not go as expected?


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Chris Murphy]

On Mon, Nov 14, 2016 at 5:01 AM, Stephen Gallagher  wrote:

> Certainly. My point is that I don't feel that we are necessarily responsible 
> for
> working around their antagonism either. Yes, it would be nice if Fedora
> supported all hardware ever made. But the simple truth is that Apple tries 
> very
> hard to make it *not* work. They have a vested interest in that.

I think you overestimate their concern. Apple tries very hard to make
Windows work on Macs. If you're thinking they simultaneously are
trying to prevent Ubuntu or Fedora from running, I think that's silly.
That's less of a concern than Hackintoshes. Apple, so far, doesn't
prevent even that, even though they could. I suspect they consider it
a non-factor or a zero sum game at this point.


> So I assert that while support for Apple hardware is desirable, I don't 
> believe
> that the lack of it should prevent us from shipping Fedora for all the other
> hardware that we do support.

Yeah but you're not being very specific where you want to draw the
line compared to any other hardware vendor who has the same outcome as
Apple hardware. And that outcomes has less to do with that vendor's
choices, than Fedora's.


-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Chris Murphy]

On Fri, Nov 11, 2016 at 5:33 AM, Stephen Gallagher  wrote:

> Just to address this specifically, I am referring to Apple's penchant for
> stuffing their machines with hardware from vendors that don't play well with
> open-source (for example, switching to wifi-only devices and shipping Broadcom
> chipsets with no open-source drivers).

I don't understand how this relates to installer problems and thus
installer release criteria. Other vendors use Broadcom and end up with
the same lack of out of the box wireless, but out of the box wireless
doesn't cause installer problems or failure (OK unless you choose to
use the netinstaller) or data loss.

>Then also playing games with their
> bootloader system so that we have to go through lots of hoops to trick it into
> letting us install.

OK I don't know what either "games" or "hoops" refer to, plural means
you must have at least two examples of each.

Their firmware works the same as any other UEFI system, except they do
additional things. The firmware can read HFS+ out of the box, and can
use information in the HFS+ volume header to boot a computer when
NVRAM contents are ambiguous or have been reset. This is because Apple
has 30+ years of experience with NVRAM corruption, loss, and confusion
that they have the same exact keyboard sequence on every single Mac
made in that 30 year period to clear the NVRAM and still boot.

If there's a game being played, it's with other vendors who could have
agreed to the same feature and keyboard sequence, and codified it in
the UEFI spec. All for the benefit of their users. But they didn't do
that did they?


> Apple's entire business model is predicated on the idea that they know best 
> and
> you should only ever run software on their devices that they have provided to
> you... at a substantial percentage for themselves. They do whatever they can 
> at
> a technical level to enable this.

They do whatever they can to enable the primary experience. They don't
go out of their way to sabotage their compatibility, quite to the
contrary, they've spent a lot of effort to accommodate Windows on
Macs.

> (Note: I'm not attempting to vilify Apple here. Their devices are usually
> sturdy, well-constructed and certainly attractive. They are however a company
> trying to make money and they have a certain business model that is largely
> dependent on *not* enabling us.)

Apple isn't doing what they're doing so that Fedora doesn't work.
They're doing what they're doing with their primary and secondary use
cases in mind only, and both of those use cases have no issue with a
dependency on proprietary components. Fedora has chosen to avoid
proprietary components, and it just has to live with the consequences
of that choice rather than rephrase the difference as if Apple and
other vendors are actively trying to prevent Fedora from being used.
Fedora isn't on any of Apple's lists.



-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Chris Murphy]

On Thu, Nov 10, 2016 at 6:44 PM, Josh Boyer 
wrote:
> On Thu, Nov 10, 2016 at 5:09 PM, Adam Williamson
>  wrote:
>> On Thu, 2016-11-10 at 13:31 -0800, Chris Murphy wrote:
>>> https://meetbot.fedoraproject.org/fedora-meeting-2/2016-11-1
0/f25-final-gono-go-meeting.2016-11-10-17.00.log.html
>>>
>>> > > > 17:10:26  i can't really vote -1 on this under the current
criteria unless someone tries on a newer mac and it works. but given
https://www.happyassassin.net/testcase_stats/25/Installation
/QA_Testcase_dualboot_with_OSX_Miscellaneous.html , i am entirely open to
dropping the criterion on the basis of failure to test.
>>>
>>>
>>> I think it's specious to drop the criterion on this basis. There are
>>> plenty of other things that don't get tested and their criterion don't
>>> get dropped.
>>
>> I am actually planning to propose precisely this.
>
> My sincere apologies for not being in the meeting.  I could not attend
> due to a conflict with a different meeting.
>
> I am somewhat befuddled at the decision to block the entire release
> for this issue.  We seem to have created a criteria under the premise
> that "lots of people have Macs and want to run Linux/Fedora on them",
> yet our empirical data seems to have shown a distinct lack of testing
> that would bear that premise out.
>
> I agree 100% that lots of people have Macs.  I agree in part that
> people want to run Linux/Fedora on them.  I agree that a subset of
> those that want to run Linux on a Mac also want to dual-boot OS X.
> What I cannot get my head around though is how we've essentially made
> a decision based on perceived marketing value of those target users at
> the expense of every other platform we support.  Our engineering and
> testing resources are clearly not sufficient to cover this case.  If
> they are, then we have a fairly large communication problem
> illustrated here.  Or if that wasn't the reason, and it was simply
> "because we have a criteria written down" that also seems somewhat
> myopic.
>
> Please don't misunderstand me.  I want this to work and I think it is
> valuable.  I also appreciate everyone pitching in at the last minute
> and I'm sure it will get fixed.  However, I think we really need to
> take a strong look at what our Project can sustain, the value of the
> distribution as a whole across all Editions and platforms, and the
> resulting impacts of every possible slip.  The conversation I read in
> the IRC logs does not seem to reflect that, and despite people wishing
> for "not hero-ing" that seems like exactly what happened and will
> continue to happen, extending even into the release itself over a
> major holiday.
>
> We are technical people and bugs bother us and we want to fix them.
> Yet, we need to make judgement calls on blockers based on reality and
> overall benefit/cost of blocking the release, not because we have a
> known root-cause at the last minute and can probably fix it if we
> slip.  That way lies madness and we'll continue to have further
> arguments about playing catch-up in the schedule with a shorter cycle
> next release, etc.  How can we ensure that we balance that with a
> broader focus across the Project so that we don't continue to have
> problems of our own making?

My perspective of this imbalance is that Anaconda churns code, and Fedora
is it's testing canary. And the consensus view is that more canaries are
needed, rather than less poison gas.

17:39:34  (i.e. it seems we have quite a lot of people who want to
install os x on macs post-release, but almost no-one who wants to test
pre-release)
17:39:39  i guess this is because 'burner macs' are rare

Adam gets this right. Mac users by and large have no concept of OS testing.
Only recently is there a public beta test program. Developers by and large
test their application for compatibility, rather than testing OS
installation - but even in pre-release testing, installer problems are
rare. In a decade of testing, I can't think of a single bug I've hit in
Apple's installer.

This is pretty much a case of in for a penny, in for a pound. Fedora
contributes specialized QA people who can do this work correctly. And out
of that you get defectors from Appleland who hopefully write some cool
stuff or contribute in ways they otherwise wouldn't.

Now, in the Go, No Go meeting logs there's this idea of changing the
criterion to take the form of a Hippocratic Oath, "do no harm" to macOS,
rather than guarantee a successful installation of Fedora. This is further
elaborated by noting even if the criterion is done away with, there's still
a concern over the vary narrow path to data loss, and that alone is reason
to block. And so now I can't help but think of this years old bug:

https://bugzilla.redhat.com/show_bug.cgi?id=1033778

In that bug, two macOS users actually do in fact experience unrecoverable
data loss. It's not hypothetical at all. QA said it was a blocker. Upstream
said it's not. And 

Re: Fedora on Macs, removing the release criterion

[Peter Robinson]

On Mon, Nov 14, 2016 at 12:58 PM, Stephen Gallagher  wrote:
> On 11/11/2016 11:03 AM, Adam Williamson wrote:
>> On Fri, 2016-11-11 at 08:33 -0500, Stephen Gallagher wrote:
>>> Just to address this specifically, I am referring to Apple's penchant for
>>> stuffing their machines with hardware from vendors that don't play well with
>>> open-source (for example, switching to wifi-only devices and shipping 
>>> Broadcom
>>> chipsets with no open-source drivers). Then also playing games with their
>>> bootloader system so that we have to go through lots of hoops to trick it 
>>> into
>>> letting us install.
>>
>> The whole 'you're only allowed to use OS X in virtualization on top of
>> real OS X' thing is fairly actively hostile too.
>>
>
> Then there's
> https://www.reddit.com/r/Ubuntu/comments/5c8s1k/warning_2016_macbook_pro_is_not_compatible_with/
> which looks like Apple is now going to start reporting incorrect PCI IDs to 
> make
> their NVMe SSDs unbootable to alternate OSes...

So really then they're just on feature parity with some of the other
modern ultra books from the likes of Lenovo then :-)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Stephen Gallagher]

On 11/13/2016 01:46 PM, Ms Sanchez wrote:
> 
> 
> On 11/11/16 14:33, Stephen Gallagher wrote:
>>
>> Just to address this specifically, I am referring to Apple's penchant for
>> stuffing their machines with hardware from vendors that don't play well with
>> open-source (for example, switching to wifi-only devices and shipping 
>> Broadcom
>> chipsets with no open-source drivers). Then also playing games with their
>> bootloader system so that we have to go through lots of hoops to trick it 
>> into
>> letting us install.
>>
>> Apple's entire business model is predicated on the idea that they know best 
>> and
>> you should only ever run software on their devices that they have provided to
>> you... at a substantial percentage for themselves. They do whatever they can 
>> at
>> a technical level to enable this.
>>
>> (Note: I'm not attempting to vilify Apple here. Their devices are usually
>> sturdy, well-constructed and certainly attractive. They are however a company
>> trying to make money and they have a certain business model that is largely
>> dependent on *not* enabling us.)
>>
>>
> 
> Apple's business model is based on selling you a golden cage.  They are 
> entitled
> to do that and we are entitled to dislike it.

Certainly. My point is that I don't feel that we are necessarily responsible for
working around their antagonism either. Yes, it would be nice if Fedora
supported all hardware ever made. But the simple truth is that Apple tries very
hard to make it *not* work. They have a vested interest in that.

So I assert that while support for Apple hardware is desirable, I don't believe
that the lack of it should prevent us from shipping Fedora for all the other
hardware that we do support.




signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Stephen Gallagher]

On 11/11/2016 11:03 AM, Adam Williamson wrote:
> On Fri, 2016-11-11 at 08:33 -0500, Stephen Gallagher wrote:
>> Just to address this specifically, I am referring to Apple's penchant for
>> stuffing their machines with hardware from vendors that don't play well with
>> open-source (for example, switching to wifi-only devices and shipping 
>> Broadcom
>> chipsets with no open-source drivers). Then also playing games with their
>> bootloader system so that we have to go through lots of hoops to trick it 
>> into
>> letting us install.
> 
> The whole 'you're only allowed to use OS X in virtualization on top of
> real OS X' thing is fairly actively hostile too.
> 

Then there's
https://www.reddit.com/r/Ubuntu/comments/5c8s1k/warning_2016_macbook_pro_is_not_compatible_with/
which looks like Apple is now going to start reporting incorrect PCI IDs to make
their NVMe SSDs unbootable to alternate OSes...



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Ms Sanchez]

On 11/11/16 14:33, Stephen Gallagher wrote:


Just to address this specifically, I am referring to Apple's penchant for
stuffing their machines with hardware from vendors that don't play well with
open-source (for example, switching to wifi-only devices and shipping Broadcom
chipsets with no open-source drivers). Then also playing games with their
bootloader system so that we have to go through lots of hoops to trick it into
letting us install.

Apple's entire business model is predicated on the idea that they know best and
you should only ever run software on their devices that they have provided to
you... at a substantial percentage for themselves. They do whatever they can at
a technical level to enable this.

(Note: I'm not attempting to vilify Apple here. Their devices are usually
sturdy, well-constructed and certainly attractive. They are however a company
trying to make money and they have a certain business model that is largely
dependent on *not* enabling us.)




Apple's business model is based on selling you a golden cage.  They are 
entitled to do that and we are entitled to dislike it.



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Ms Sanchez]

On 11/11/16 10:08, Fabio Alessandro Locati wrote:


  

The reason is pretty simple: very few people have a disposable Mac.
About 90% of the time, the Mac people want to install Fedora on is
their personal laptop. So of course they're not willing to test
installing some random pre-Beta nightly snapshot and tell us if
everything explodes. We also can't i) easily or ii) legally (AFAIK)
install OS X into a VM on non-Apple hardware for testing.

I don't see why people should not have a disposable Macs but is "normal"
to have a disposable PC.
Also, AFAIK, Mac users tend to substitute their machines more often than
PC users (at least statistically speaking), so many of them should have
a 2-3 years old machine laying around.
  




Maybe because Apple stuff is very expensive?  It's not the kind of 
device you buy one day and dump it to the garbage in the next one... I 
think.



Cheers,
Sylvia

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Ms Sanchez]

On 12/11/16 08:13, Kevin Kofler wrote:


How is it "at the expense of every other platform we support"? It's not like
the fix is going to stop them from working. It is not a catastrophe to ship
one week later.

I don't use a Mac, I also don't dual-boot, but still I fail to see why this
issue should be rejected as a blocker just to ship a week earlier. Fedora
really needs to decrease the pressure to not slip, in order to ensure a
reasonable quality of our releases. Blockers must be fixed no matter how
long it takes.

 Kevin Kofler
___




Totally agree. It's always better to have a high quality system to offer 
whether it's released earlier or later, than a poor quality system that 
may fail and give a terrible impression to newcomers just for the sake 
of a fixed schedule.


My 2 cents.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Kevin Kofler]

Josh Boyer wrote:
> What I cannot get my head around though is how we've essentially made
> a decision based on perceived marketing value of those target users at
> the expense of every other platform we support.

How is it "at the expense of every other platform we support"? It's not like 
the fix is going to stop them from working. It is not a catastrophe to ship 
one week later.

I don't use a Mac, I also don't dual-boot, but still I fail to see why this 
issue should be rejected as a blocker just to ship a week earlier. Fedora 
really needs to decrease the pressure to not slip, in order to ensure a 
reasonable quality of our releases. Blockers must be fixed no matter how 
long it takes.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Andreas Tunek]

2016-11-11 10:04 GMT+01:00 Fabio Alessandro Locati :
> On Fri, Nov 11, 2016 at 09:20:08AM +0100, Andreas Tunek wrote:
>> As a mac owner (although one that is not very well supported by
>> Linux*) I really appreciate the fact that Fedora works. And saying you
>> do not want to support that hardware anymore just because you found a
>> regression/bug is kind of lame.
>
> Hi,
>
> No one is saying that we should not support Macs, only that if Mac
> support is broken, this should not block a whole release.
>

If you can't actually install Fedora on a system you do not support
it. What is your suggestion, should there be a special image created
just for macs at a later date?

/Andreas

> Best,
> Fale
> --
> Fabio Alessandro Locati
> Red Hat - Senior Consultant
>
> PGP Fingerprint: E815 3C49 2A8D FD8B 1CBD  BC85 FDB3 DF20 B2DC 9C1B
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Adam Williamson]

On Fri, 2016-11-11 at 19:19 +, Peter Robinson wrote:
> On Fri, Nov 11, 2016 at 12:55 PM, Josh Boyer  
> wrote:
> > On Fri, Nov 11, 2016 at 7:43 AM, Michael Catanzaro  
> > wrote:
> > > My $0.02 is that none of the reasons we requested the blocker criterion
> > > have changed. Dual boot with macOS is very important to attracting new
> > > users -- we're explicitly targeting macOS users, that's the user group
> > > where we think we have real potential for significant growth -- and I
> > > continue to prefer we block the release indefinitely if it's not
> > > working. We can't afford for our next Ars review to say "the installer
> > > is broken, try again next year."
> > 
> > Then we, as a project, need to back that up with sufficient hardware
> > and test resources.  Otherwise it is nothing more than a wish and will
> > continue to lead to problems like this.
> 
> And multi boot issues, which can be quite complex and nuanced, should
> then I believe also be a beta blocker (or at least well tested in the
> lead up to beta) to ensure issues get enough attention early enough in
> the release so as to not block GA.

The question of how early we should test things (ideally we should test
everything all the time, but you know how that goes) is really quite
separate from the question of which release they should block.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Adam Williamson]

On Fri, 2016-11-11 at 09:41 -0800, Richard Johnson wrote:
> I'm very new to this but I'd like to help out.  I actually saw the
> problem a little while back, when I tried to mount an HFS+ FS onto my
> Fedora mac.  It mounted ro.

That in itself is not a bug (except in the sense of 'missing feature').
It's intended to do that, because the Linux HFS+ support cannot safely
write to journalled HFS+. So when the HFS+ filesystem has journalling
enabled, it's intentionally mounted read-only.

The actual issue in the blocker bug is basically that blivet (the
storage module anaconda uses) misidentifies the macOS partition as
being an existing 'macefi' partition and tries to re-use it.

'macefi' partitions are a slightly odd thing we invented basically to
trick Macs into showing Fedora on their nice graphical boot menu. I can
explain in more detail if you like, but you don't really need to know,
all you need to know is that anaconda thinks the macOS partition (which
it absolutely shouldn't do anything at all to) is something else
entirely, and tries to mount it and write stuff to it. Which means
that:

i) Fedora won't boot, because for Fedora to boot we need to find or
create a *real* macefi partition and write to it

ii) If the macOS partition could be mounted read-write we would
probably nuke your macOS install very badly, but fortunately, it almost
never will be (only if you'd explicitly disabled journalling on it for
some reason)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Peter Robinson]

On Fri, Nov 11, 2016 at 12:55 PM, Josh Boyer  wrote:
> On Fri, Nov 11, 2016 at 7:43 AM, Michael Catanzaro  
> wrote:
>> My $0.02 is that none of the reasons we requested the blocker criterion
>> have changed. Dual boot with macOS is very important to attracting new
>> users -- we're explicitly targeting macOS users, that's the user group
>> where we think we have real potential for significant growth -- and I
>> continue to prefer we block the release indefinitely if it's not
>> working. We can't afford for our next Ars review to say "the installer
>> is broken, try again next year."
>
> Then we, as a project, need to back that up with sufficient hardware
> and test resources.  Otherwise it is nothing more than a wish and will
> continue to lead to problems like this.

And multi boot issues, which can be quite complex and nuanced, should
then I believe also be a beta blocker (or at least well tested in the
lead up to beta) to ensure issues get enough attention early enough in
the release so as to not block GA.

Peter
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Richard Johnson]

I'm very new to this but I'd like to help out.  I actually saw the problem a 
little while back, when I tried to mount an HFS+ FS onto my Fedora mac.  It 
mounted ro.  I would definitely be interested in helping out on "fedora on Mac" 
testing.  I'm currently looking through bugzilla to see if there's something on 
which I can help out.  Any other pointers to how to get involved more would be 
greatly appreciated.

/raj


> On Nov 11, 2016, at 8:46 AM, Stephen John Smoogen  wrote:
> 
> On 11 November 2016 at 03:20, Andreas Tunek  wrote:
>> 
>> 
>> As a mac owner (although one that is not very well supported by
>> Linux*) I really appreciate the fact that Fedora works. And saying you
>> do not want to support that hardware anymore just because you found a
>> regression/bug is kind of lame.
> 
> You are reading that wrong. The problem isn't that we don't want to
> support Mac hardware, we are finding we can't support Mac hardware to
> the level that it blocks a release because there are not enough people
> testing the hardware in a fashion that finds blocker level bugs.
> 
> This is where you and other Mac users can and MUST help out. Fedora is
> a stone soup. Unless people bring some amount of work to the pot, what
> they get out is water flavoured gravel.  You can bring the spice and
> aroma of a Mac hardware.. but if you don't then it doesn't mean that
> we can wait until someone else does.
> 
> -- 
> Stephen J Smoogen.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Stephen John Smoogen]

On 11 November 2016 at 03:20, Andreas Tunek  wrote:
>
>
> As a mac owner (although one that is not very well supported by
> Linux*) I really appreciate the fact that Fedora works. And saying you
> do not want to support that hardware anymore just because you found a
> regression/bug is kind of lame.

You are reading that wrong. The problem isn't that we don't want to
support Mac hardware, we are finding we can't support Mac hardware to
the level that it blocks a release because there are not enough people
testing the hardware in a fashion that finds blocker level bugs.

This is where you and other Mac users can and MUST help out. Fedora is
a stone soup. Unless people bring some amount of work to the pot, what
they get out is water flavoured gravel.  You can bring the spice and
aroma of a Mac hardware.. but if you don't then it doesn't mean that
we can wait until someone else does.

-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Adam Williamson]

On Fri, 2016-11-11 at 08:33 -0500, Stephen Gallagher wrote:
> Just to address this specifically, I am referring to Apple's penchant for
> stuffing their machines with hardware from vendors that don't play well with
> open-source (for example, switching to wifi-only devices and shipping Broadcom
> chipsets with no open-source drivers). Then also playing games with their
> bootloader system so that we have to go through lots of hoops to trick it into
> letting us install.

The whole 'you're only allowed to use OS X in virtualization on top of
real OS X' thing is fairly actively hostile too.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Adam Williamson]

On Fri, 2016-11-11 at 09:08 +, Fabio Alessandro Locati wrote:
> I think VM testing on Mac would not produce any more insights than VM
> testing on PC.

VM testing on PCs produces plenty of insights, it's how we do *most*
testing now. It's perfectly fine for testing bootloader stuff, for
instance, so long as the firmware used by the VM decently approximates
the behaviour of real system firmware (I don't know if that's the case
for 'approved' Apple virtualization things, admittedly).
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Paul W. Frields]

On Fri, Nov 11, 2016 at 07:55:06AM -0500, Josh Boyer wrote:
> On Fri, Nov 11, 2016 at 7:43 AM, Michael Catanzaro  
> wrote:
> > My $0.02 is that none of the reasons we requested the blocker criterion
> > have changed. Dual boot with macOS is very important to attracting new
> > users -- we're explicitly targeting macOS users, that's the user group
> > where we think we have real potential for significant growth -- and I
> > continue to prefer we block the release indefinitely if it's not
> > working. We can't afford for our next Ars review to say "the installer
> > is broken, try again next year."
> 
> Then we, as a project, need to back that up with sufficient hardware
> and test resources.  Otherwise it is nothing more than a wish and will
> continue to lead to problems like this.

Adam W pinpointed an issue with "burner" Macs.  I have a MBP myself
that I treat as an appliance.  I use it for Pro Tools and my non-FOSS
related creative pursuits.  I'm well aware of Apple's tactics when it
comes to tight integration and OS/HW integrity.  I don't mess with it
at a low level, and don't test bare-metal installation on it (although
I do test the live OS from USB).

Also Michael pointed out something about a certain big company ;-)
needing to provide hardware for the QA team.  To the best of my
knowledge, that company doesn't have a stake in putting products on
e.g. Mac laptops.  This is a community project, so let's see how we
can handle this as a community, starting with the Workstation WG (as
opposed to QA).

That being said, I arranged to get an additional drive with some small
$$ available from said company.  I can use it to help with testing,
since I happen to have hardware.  My hope is other Workstation WG
members will join me.  Else we *do* look at removing criteria, not
just throw them over the wall and expect QA to deal with it.

-- 
Paul W. Frieldshttp://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
  http://redhat.com/   -  -  -  -   http://pfrields.fedorapeople.org/
The open source story continues to grow: http://opensource.com
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Stephen Gallagher]

On 11/10/2016 04:31 PM, Chris Murphy wrote:
> https://meetbot.fedoraproject.org/fedora-meeting-2/2016-11-10/f25-final-gono-go-meeting.2016-11-10-17.00.log.html

 17:12:02  I've never understood why we would block on failures 
 to run on hardware that actively tries to make it difficult to run Linux 
 on.
> 
> Please elaborate on what this means. Specifically I have no idea what
> the word "actively" is referring to.
> 

Just to address this specifically, I am referring to Apple's penchant for
stuffing their machines with hardware from vendors that don't play well with
open-source (for example, switching to wifi-only devices and shipping Broadcom
chipsets with no open-source drivers). Then also playing games with their
bootloader system so that we have to go through lots of hoops to trick it into
letting us install.

Apple's entire business model is predicated on the idea that they know best and
you should only ever run software on their devices that they have provided to
you... at a substantial percentage for themselves. They do whatever they can at
a technical level to enable this.

(Note: I'm not attempting to vilify Apple here. Their devices are usually
sturdy, well-constructed and certainly attractive. They are however a company
trying to make money and they have a certain business model that is largely
dependent on *not* enabling us.)



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Matthew Miller]

On Thu, Nov 10, 2016 at 07:09:39PM -0800, Adam Williamson wrote:
> It's also worth noting that there's a possible scenario where we could
> completely nerf the OS X install here. It's a fairly *unlikely*
> scenario - the user would have to manually disable journalling on the
> macOS partition - but it is *possible*. For instance, they may have
> disabled it so they could write to the partition in Linux, for some
> reason, and then forgotten to re-enable it. So this bug, at least in
> that case, can be even worse than just 'Fedora doesn't boot'. It can be
> 'the Fedora installer ate my OS X kernel'.

Yeah -- that's what pushed me over the edge on this.

That and I'm not *super* keen on the practice of removing blocker
criteria whenever we hit them

> I don't really *like* the thing where we suddenly decide at the end of
> the release cycle that we don't like a criterion that *just happens* to
> be standing in the way of release after all, and magically say it's not
> a criterion any more. It's crappy process. But we have done it before

Yeah, that :)



-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Josh Boyer]

On Fri, Nov 11, 2016 at 7:43 AM, Michael Catanzaro  wrote:
> My $0.02 is that none of the reasons we requested the blocker criterion
> have changed. Dual boot with macOS is very important to attracting new
> users -- we're explicitly targeting macOS users, that's the user group
> where we think we have real potential for significant growth -- and I
> continue to prefer we block the release indefinitely if it's not
> working. We can't afford for our next Ars review to say "the installer
> is broken, try again next year."

Then we, as a project, need to back that up with sufficient hardware
and test resources.  Otherwise it is nothing more than a wish and will
continue to lead to problems like this.

josh
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Michael Catanzaro]

My $0.02 is that none of the reasons we requested the blocker criterion
have changed. Dual boot with macOS is very important to attracting new
users -- we're explicitly targeting macOS users, that's the user group
where we think we have real potential for significant growth -- and I
continue to prefer we block the release indefinitely if it's not
working. We can't afford for our next Ars review to say "the installer
is broken, try again next year."

On Fri, 2016-11-11 at 00:34 -0800, Adam Williamson wrote:
> We could, I suppose, try to get a few Mac users to look into testing
> in
> VMs on their Macs. But beyond that we need people with 'burner' Macs,
> and there aren't very many of them. We (Fedora QA) have just one old
> Mac Mini.

You work for a multibillion dollar corporation where the QA team cannot
afford to buy a laptop?

Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Peter Robinson]

>> > On Fri, Nov 11, 2016 at 12:34:20AM -0800, Adam Williamson wrote:
>> >> One thing I forgot to mention in my original reply to jwb (it was
>> >> getting long) is that there's a conundrum that applies quite
>> >> specifically to Mac support, and it's this: there are quite a lot of
>> >> people who want to run Fedora on Macs (seemingly, at least) but very
>> >> few in a position to test installs for new releases.
>> >
>> > Hi,
>> >
>> > I think this is a big problem.
>> > If we have a "class" of users that have special needs (aka: very
>> > specific hardware/software/bios/...) and they never tests things, I see
>> > this more as their problem than other people problem.
>>
>> I see it as everyone's problem. A bad user experience for an entire
>> class of users is not good for the project as a whole. I don't see the
>> them and us
>
> Hi,
>
> I see the "them and us" only in the sense that the people outside that
> class can not perform testing and therefore the number of tester is very
> limited.
> Same can apply to other kind of setup that have very specific hardware
> compatibilities (ie: secondary arch).

I think you mean Alternate Architectures. We have primary and
secondary release artifacts which can be any architecture including
x86_64.

> Obviously if a company wants to test and support this actively can do so,
> but imho this burden should not be on the wider community.

Often those companies also bring a broad set of resources that benefit
the rest of the community on x86_64 as much, or often even more than
the benefit they get. You might not be aware but the alternate
architectures and their associated "companies" contribute a lot of
resources (both human and other) to Fedora to improve it as a whole.
Like everything else in a community it's give and take.

>> I generally haven't seen that trend. The mac users I know often keep
>> their devices as long as they are usable as they cost so much or they
>> upgrade every time there's a new model and sell the old one ASAP to
>> recoup some of the costs. For corp use this is often different but
>> then it is with all laptops.
>
> This is true. Often Mac users that upgrade frequently sell their old Macs,
> while this is less common in the PC world.
>
> Best,
> Fale
> --
> Fabio Alessandro Locati
> Red Hat - Senior Consultant
>
> PGP Fingerprint: E815 3C49 2A8D FD8B 1CBD  BC85 FDB3 DF20 B2DC 9C1B
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org