Re: release criteria for final - bug 1320967

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, May 20, 2016 at 4:48 PM, Adam Williamson
<adamwill@xxxxxxxxxxxxxxxxx> wrote:
> On Fri, 2016-05-20 at 15:59 -0600, Chris Murphy wrote:

>> Not every bug limits the test coverage so dramatically to require
>> that.
>
> I'm not sure I particularly buy that. Are there really a lot of people
> testing pre-releases by dual-booting who can't navigate the UEFI boot
> menu? I mean, it's possible, but I haven't got that impression...

There's a lot of hardware out there with fast boot, which if enabled
means USB is not initialized at boot and you can't get to firmware
setup or the boot manager at boot time. My little Intel NUC has such a
feature, but it didn't come with Windows, didn't have either fast boot
or Secure Boot enabled by default. I have no idea how prevalent this
hardware is, or the setting. That setting definitely makes boots a LOT
faster.



>
>>  And I'm not certain this one does either
>
> Right.
>
>> . But this bug does
>> inhibit Windows boot, even if it's not nerfed, from GRUB for people
>> with UEFI systems where it was previously working, when they upgrade
>> to beta (which I don't think have any scary warnings like anaconda
>> pre-releases).
>
> Well, you kinda have to read the instructions to upgrade to a Beta, and
> the instructions do of course include all the warnings.

At beta download, Common bugs is at least as prominent, if not more
so, than the download itself. So, I think there's an OK buyer beware
gate.








>
>>
>> > It doesn't work that way. There has to be a trade-off between what we'd
>> > like and what we can actually achieve. Of course it'd be nice if
>> > everything worked all the time. I don't think you'll be able to sell
>> > pjones on this being an Alpha blocker.
>>
>> I wouldn't buy off on it as an alpha blocker either. I might buy off
>> on it being beta, but even there I'm skeptical as there is a work
>> around. But what if there isn't a work around at all? I suppose in
>> that case the catch all you hate for limiting test coverage would just
>> apply in which case strictly speaking no change in criterion is needed
>> here.
>
> I'm still not really convinced it applies.

I think it's a hypothetical that isn't worth further discussion, if
the bug were bad enough with no work arounds and therefore
significantly impacts test coverage, just vote on using the catch all.
At least, until you make it go bye bye.


-- 
Chris Murphy
--
test mailing list
test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe:
http://lists.fedoraproject.org/admin/lists/test@xxxxxxxxxxxxxxxxxxxxxxx




[Index of Archives]     [Fedora Desktop]     [Fedora SELinux]     [Photo Sharing]     [Yosemite Forum]     [KDE Users]

  Powered by Linux