6:34 p.m.
At the Fedora 19 Final Go/No-Go Meeting that just occurred, it was
agreed to Go with the Fedora 19 by Fedora QA, development, release
engineering and FPM.
Fedora 19 will be publicly available on Tuesday, July 02, 2013.
Thank you everyone for heroic effort on this release!
Meeting details can be seen here:
Minutes: http://bit.ly/12oSkZZ
Log: http://bit.ly/1csjMro
The Cat: http://bit.ly/11M5q3V
Jaroslav
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
11 a.m.
On Thu, Jun 27, 2013 at 07:34:06PM -0400, Jaroslav Reznik wrote:
At the Fedora 19 Final Go/No-Go Meeting that just occurred, it was
agreed to Go with the Fedora 19 by Fedora QA, development, release
engineering and FPM.
979205 got filed yesterday, which makes it incredibly difficult to
install F19 on Macs while keeping OS X. This is rather frustrating,
since Fedora's the only distribution with any significant support for
running on Apple hardware. There's two problems here:
1) QA apparently don't have any Macs, so it's difficult to test this
case
2) Policy says that once the go decision has been made, there's no way
to revoke it
(1) is something that we really need to solve, because it's clearly
unreasonable to expect community members to have a test Mac to install
every RC.
(2) is stranger. Obviously once an image is released, we're not going to
be able to recall it, and we have no history of producing updated
install images. But right now we're in a window where we haven't
officially shipped anything and are saying we can't fix this issue
purely because we've written a policy that says we can't.
There are workarounds - users can either perform custom partitioning,
wipe their disk entirely or install using beta and then upgrade to
final. It's not an utter disaster. However, if it had been caught 12
hours earlier, we'd probably have been willing to delay the release to
fix it.
I don't know that there's a good answer here. It's unfortunate to ship
with somewhat broken support for a widespread class of hardware,
especially when Fedora's compatibility with that hardware is a unique
selling point. But I don't know that it's worth going through the misery
of trying to delay things at this point, especially since the US
holidays next week seem to be the kind of thing designed to turn any
small slip into weeks.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
11:25 a.m.
On Fri, 28 Jun 2013 17:00:40 +0100
Matthew Garrett <mjg59(a)srcf.ucam.org> wrote:
979205 got filed yesterday, which makes it incredibly difficult to
install F19 on Macs while keeping OS X. This is rather frustrating,
since Fedora's the only distribution with any significant support for
running on Apple hardware. There's two problems here:
1) QA apparently don't have any Macs, so it's difficult to test this
case
2) Policy says that once the go decision has been made, there's no
way to revoke it
(1) is something that we really need to solve, because it's clearly
unreasonable to expect community members to have a test Mac to
install every RC.
(2) is stranger. Obviously once an image is released, we're not going
to be able to recall it, and we have no history of producing updated
install images. But right now we're in a window where we haven't
officially shipped anything and are saying we can't fix this issue
purely because we've written a policy that says we can't.
It's not strange to me. Once "go" happens there's a lot of wheels that
start in motion:
- Press/announcements/scheduling. Things like release day parties,
ordering media to give out at events, reviewers in press, etc.
- Branched nightly compose is disabled, 0 day updates populated. If we
needed to pick things out of updates to re-add to the base repo we
would have to reverse this, which is of course possible, but a
gigantic hassle, something we have never done before so likely error
prone, etc.
- Content is staging to mirrors. We could of course tweak this content,
but mirrors are expecting it now and may not like having to re-sync
large content like isos. Note that a fedora release is not "an
image". It's a pretty staggering amount of content. ;)
and finally the big one:
- Say we ground all the wheels to a halt and slipped for this bug.
Where to do we draw the line? If someone comes up with a bug at
9:50am on release morning, do we cancel everything? There has to be a
point where we say "sorry, it's too late" and this has been it since
it makes sense from a logistic standpoint.
Hopefully this makes sense.
kevin
11:39 a.m.
On Fri, Jun 28, 2013 at 10:25:58AM -0600, Kevin Fenzi wrote:
- Say we ground all the wheels to a halt and slipped for this bug.
Where to do we draw the line? If someone comes up with a bug at
9:50am on release morning, do we cancel everything? There has to be a
point where we say "sorry, it's too late" and this has been it since
it makes sense from a logistic standpoint.
If at 9:50am on release morning we discovered that the installer would
format all connected drives if the month had two digits, I'd like to
think we'd do something about it. It's inevitably going to be a
judgement call based on the perceived harm in releasing as is against
the harm caused by slipping, just as it is at any other point in the
release process. Current policy effectively says "There is no issue
sufficient to delay release after we've said an image is good", and I
don't believe that that's true.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
12:13 p.m.
On Fri, 2013-06-28 at 17:00 +0100, Matthew Garrett wrote:
On Thu, Jun 27, 2013 at 07:34:06PM -0400, Jaroslav Reznik wrote:
> At the Fedora 19 Final Go/No-Go Meeting that just occurred, it was
> agreed to Go with the Fedora 19 by Fedora QA, development, release
> engineering and FPM.
979205 got filed yesterday, which makes it incredibly difficult to
install F19 on Macs while keeping OS X. This is rather frustrating,
since Fedora's the only distribution with any significant support for
running on Apple hardware. There's two problems here:
1) QA apparently don't have any Macs, so it's difficult to test this
case
2) Policy says that once the go decision has been made, there's no way
to revoke it
(1) is something that we really need to solve, because it's clearly
unreasonable to expect community members to have a test Mac to install
every RC.
So turns out I was wrong on that: "we", (by which I think you mean "paid
Red Hat QA staff" - we certainly have regular testers with Macs, Chris
is one of them) do have a UEFI Mac Mini in Brno, we arranged that last
year. What we don't have is a test case for Mac dual-boot. This is
because it hasn't really been considered to be a release requirement
(ever, this release is no different from any previous one). We have a
dual-boot with Windows test and explicit criterion:
"The installer must be able to install into free space alongside an
existing clean single-partition Windows installation and either install
a bootloader which can boot into the Windows installation, or leave the
Windows bootloader untouched and working"
https://fedoraproject.org/wiki/QA:Testcase_dualboot_with_windows
But we do not have anything corresponding for Macs. This was a conscious
decision made in the past, not an omission. If we now think it is
realistic and worthwhile to support dual boot on Macs we can re-consider
that decision, but it would be an explicit policy change, not just
rectifying an oversight or something.
(I'll note that, quite honestly, I wouldn't consider UEFI dual/multi
boot of any kind remotely robust as things stand. It still appears to be
very much a work in progress. The only thing that we really have code
for that I'd vaguely stand behind is Windows BIOS dual boot.)
(2) is stranger. Obviously once an image is released, we're not
going to
be able to recall it, and we have no history of producing updated
install images. But right now we're in a window where we haven't
officially shipped anything and are saying we can't fix this issue
purely because we've written a policy that says we can't.
Well, the policy was presumably not yanked out of thin air. It predates
my arrival at RH/Fedora, so I don't know personally the reasoning behind
it, but I can guess that a lot of it has to do with release engineering
and website logistics. We need to have a definite point of no return in
order to do a final stable push, mash, unfreeze the updates repo and
stage everything out to mirrors. That's not an overnight operation. I'm
not releng so I don't know for sure, but it may well be that at this
stage in the game it isn't actually straightforward/possible to
'un-Gold'.
There are workarounds - users can either perform custom partitioning,
wipe their disk entirely or install using beta and then upgrade to
final. It's not an utter disaster. However, if it had been caught 12
hours earlier, we'd probably have been willing to delay the release to
fix it.
I'm not actually sure that's the case. As I said above, we don't have a
release requirement for this and that is at least in part an explicit
choice, not an oversight. We explicitly did not consider Mac dual boot a
case we wanted to commit to 'supporting' in the past.
I'll also note that we haven't _definitely_ confirmed the issue as
described yet. Chris is a good tester, but single testers can always get
things wrong. I would like it if someone else with a Mac can return it
as close to a stock factory configuration as possible and try a Fedora
19 install on the simplest possible path and confirm that they hit the
bug.
There is another 'workaround' you haven't considered: we can simply
build an updates.img that fixes the issue (or works around it, by
ditching the commit from 19.13.10 that apparently broke this case), and
link to that from the common bugs page and the bug itself.
I don't know that there's a good answer here. It's
unfortunate to ship
with somewhat broken support for a widespread class of hardware,
especially when Fedora's compatibility with that hardware is a unique
selling point.
Well, I'd say _limited_ compatibility. We've had all kinds of bugs in
Mac support in, well, pretty much all previous releases too. It's not as
if we have a track record of excellent support, we have a track record
of 'you can probably kind of make it work if you try hard enough'.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
12:19 p.m.
On Fri, Jun 28, 2013 at 1:13 PM, Adam Williamson <awilliam(a)redhat.com> wrote:
There is another 'workaround' you haven't considered: we
can simply
build an updates.img that fixes the issue (or works around it, by
ditching the commit from 19.13.10 that apparently broke this case), and
link to that from the common bugs page and the bug itself.
I asked Matthew and Brian about that earlier. It can be done, but
most Macs don't have working wireless until after install because b43
and sucky firmware. So any updates.img would likely need to be stuck
on a USB key. Something to keep in mind if it gets written up for
common bugs.
josh
12:24 p.m.
On Fri, 2013-06-28 at 13:19 -0400, Josh Boyer wrote:
On Fri, Jun 28, 2013 at 1:13 PM, Adam Williamson
<awilliam(a)redhat.com> wrote:
> There is another 'workaround' you haven't considered: we can simply
> build an updates.img that fixes the issue (or works around it, by
> ditching the commit from 19.13.10 that apparently broke this case), and
> link to that from the common bugs page and the bug itself.
I asked Matthew and Brian about that earlier. It can be done, but
most Macs don't have working wireless until after install because b43
and sucky firmware. So any updates.img would likely need to be stuck
on a USB key. Something to keep in mind if it gets written up for
common bugs.
Yee, I just _love_ me some Macs. Thanks; I'll take that into account for
commonbugs. When did Macs stop having ethernet ports?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
12:26 p.m.
If at 9:50am on release morning, aliens threatened to blow up the
world if we shipped, we'd certainly do something about it.
But it would be insane to expect us to *document* that we'd do
something about it.
IMHO it's perfectly reasonable for documented policy to simply say
"bugs after this point won't stop a release" because there are
rational people behind the process to handle exceptional cases, and no
amount of imagined example scenarios make the policy any less
appropriate.
12:31 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 06/28/2013 01:24 PM, Adam Williamson wrote:
On Fri, 2013-06-28 at 13:19 -0400, Josh Boyer wrote:
> On Fri, Jun 28, 2013 at 1:13 PM, Adam Williamson
> <awilliam(a)redhat.com> wrote:
>> There is another 'workaround' you haven't considered: we can
>> simply build an updates.img that fixes the issue (or works
>> around it, by ditching the commit from 19.13.10 that apparently
>> broke this case), and link to that from the common bugs page
>> and the bug itself.
>
> I asked Matthew and Brian about that earlier. It can be done,
> but most Macs don't have working wireless until after install
> because b43 and sucky firmware. So any updates.img would likely
> need to be stuck on a USB key. Something to keep in mind if it
> gets written up for common bugs.
Yee, I just _love_ me some Macs. Thanks; I'll take that into
account for commonbugs. When did Macs stop having ethernet ports?
When the MacBook Air became the flagship Mac.
I think most MacBook Pro and all desktop models still have one, though.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlHNyHgACgkQeiVVYja6o6OnLQCfX/5aCPIlO3oKdMIMjkGl5aqx
jYMAnj7tL3QOEnkLGxCnQxuLCNjTHBjK
=Qv+k
-----END PGP SIGNATURE-----
12:33 p.m.
On Fri, Jun 28, 2013 at 1:31 PM, Stephen Gallagher <sgallagh(a)redhat.com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 06/28/2013 01:24 PM, Adam Williamson wrote:
> On Fri, 2013-06-28 at 13:19 -0400, Josh Boyer wrote:
>> On Fri, Jun 28, 2013 at 1:13 PM, Adam Williamson
>> <awilliam(a)redhat.com> wrote:
>>> There is another 'workaround' you haven't considered: we can
>>> simply build an updates.img that fixes the issue (or works
>>> around it, by ditching the commit from 19.13.10 that apparently
>>> broke this case), and link to that from the common bugs page
>>> and the bug itself.
>>
>> I asked Matthew and Brian about that earlier. It can be done,
>> but most Macs don't have working wireless until after install
>> because b43 and sucky firmware. So any updates.img would likely
>> need to be stuck on a USB key. Something to keep in mind if it
>> gets written up for common bugs.
>
> Yee, I just _love_ me some Macs. Thanks; I'll take that into
> account for commonbugs. When did Macs stop having ethernet ports?
>
When the MacBook Air became the flagship Mac.
I think most MacBook Pro and all desktop models still have one, though.
The MacBook Pro I have does not have an ethernet port. It's a 10,2 model.
josh
12:33 p.m.
On Fri, 2013-06-28 at 13:31 -0400, Stephen Gallagher wrote:
On 06/28/2013 01:24 PM, Adam Williamson wrote:
> On Fri, 2013-06-28 at 13:19 -0400, Josh Boyer wrote:
>> On Fri, Jun 28, 2013 at 1:13 PM, Adam Williamson
>> <awilliam(a)redhat.com> wrote:
>>> There is another 'workaround' you haven't considered: we can
>>> simply build an updates.img that fixes the issue (or works
>>> around it, by ditching the commit from 19.13.10 that apparently
>>> broke this case), and link to that from the common bugs page
>>> and the bug itself.
>>
>> I asked Matthew and Brian about that earlier. It can be done,
>> but most Macs don't have working wireless until after install
>> because b43 and sucky firmware. So any updates.img would likely
>> need to be stuck on a USB key. Something to keep in mind if it
>> gets written up for common bugs.
>
> Yee, I just _love_ me some Macs. Thanks; I'll take that into
> account for commonbugs. When did Macs stop having ethernet ports?
When the MacBook Air became the flagship Mac.
It was a genuine question, not a rhetorical 'OMG how can they not have
ethernet?!?' one - I was hoping for some specifics. It'll affect the
tone of the common bugs entry.
I think most MacBook Pro and all desktop models still have one,
though.
I figured desktops, but wasn't sure about MBPs. Thanks.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
12:38 p.m.
On Fri, Jun 28, 2013 at 01:26:52PM -0400, DJ Delorie wrote:
If at 9:50am on release morning, aliens threatened to blow up the
world if we shipped, we'd certainly do something about it.
But it would be insane to expect us to *document* that we'd do
something about it.
Why? "Beyond this point the release will only be delayed if an issue is
discovered that is deemed of exceptional importance" is a perfectly
reasonable thing to document.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
12:39 p.m.
On Fri, Jun 28, 2013 at 6:33 PM, Adam Williamson <awilliam(a)redhat.com> wrote:
On Fri, 2013-06-28 at 13:31 -0400, Stephen Gallagher wrote:
> On 06/28/2013 01:24 PM, Adam Williamson wrote:
> > On Fri, 2013-06-28 at 13:19 -0400, Josh Boyer wrote:
> >> On Fri, Jun 28, 2013 at 1:13 PM, Adam Williamson
> >> <awilliam(a)redhat.com> wrote:
> >>> There is another 'workaround' you haven't considered: we
can
> >>> simply build an updates.img that fixes the issue (or works
> >>> around it, by ditching the commit from 19.13.10 that apparently
> >>> broke this case), and link to that from the common bugs page
> >>> and the bug itself.
> >>
> >> I asked Matthew and Brian about that earlier. It can be done,
> >> but most Macs don't have working wireless until after install
> >> because b43 and sucky firmware. So any updates.img would likely
> >> need to be stuck on a USB key. Something to keep in mind if it
> >> gets written up for common bugs.
> >
> > Yee, I just _love_ me some Macs. Thanks; I'll take that into
> > account for commonbugs. When did Macs stop having ethernet ports?
>
> When the MacBook Air became the flagship Mac.
It was a genuine question, not a rhetorical 'OMG how can they not have
ethernet?!?' one - I was hoping for some specifics. It'll affect the
tone of the common bugs entry.
> I think most MacBook Pro and all desktop models still have one, though.
I figured desktops, but wasn't sure about MBPs. Thanks.
I don't think any of the thunderbolt equipped MBPs (or maybe the later
ones) have them. The thunderbolt ethernet adapters apparently work if
you plug them in before you power them on and presumably all the usb
ethernet adapters would work as an option.
Peter
12:39 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 06/28/2013 01:33 PM, Adam Williamson wrote:
On Fri, 2013-06-28 at 13:31 -0400, Stephen Gallagher wrote:
> On 06/28/2013 01:24 PM, Adam Williamson wrote:
>> On Fri, 2013-06-28 at 13:19 -0400, Josh Boyer wrote:
>>> On Fri, Jun 28, 2013 at 1:13 PM, Adam Williamson
>>> <awilliam(a)redhat.com> wrote:
>>>> There is another 'workaround' you haven't considered: we
>>>> can simply build an updates.img that fixes the issue (or
>>>> works around it, by ditching the commit from 19.13.10 that
>>>> apparently broke this case), and link to that from the
>>>> common bugs page and the bug itself.
>>>
>>> I asked Matthew and Brian about that earlier. It can be
>>> done, but most Macs don't have working wireless until after
>>> install because b43 and sucky firmware. So any updates.img
>>> would likely need to be stuck on a USB key. Something to
>>> keep in mind if it gets written up for common bugs.
>>
>> Yee, I just _love_ me some Macs. Thanks; I'll take that into
>> account for commonbugs. When did Macs stop having ethernet
>> ports?
>
> When the MacBook Air became the flagship Mac.
It was a genuine question, not a rhetorical 'OMG how can they not
have ethernet?!?' one - I was hoping for some specifics. It'll
affect the tone of the common bugs entry.
> I think most MacBook Pro and all desktop models still have one,
> though.
I figured desktops, but wasn't sure about MBPs. Thanks.
Actually, looks like the Retina Display models don't include ethernet
either (they have an ethernet-to-thunderbolt adapter for sale instead).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlHNymgACgkQeiVVYja6o6P8TgCggYxRYaqsH5zz/OlFrw3M89+9
IbUAnRBwd/OQGcfBO0aUysKycDoKvtMU
=ysLq
-----END PGP SIGNATURE-----
12:40 p.m.
On Fri, Jun 28, 2013 at 10:13:15AM -0700, Adam Williamson wrote:
Well, I'd say _limited_ compatibility. We've had all kinds of
bugs in
Mac support in, well, pretty much all previous releases too. It's not as
if we have a track record of excellent support, we have a track record
of 'you can probably kind of make it work if you try hard enough'.
Since F17 we've had a track record of "It'll work fine, as long as you
don't hit a kernel bug". Which is exactly where we are with every other
platform.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
12:43 p.m.
On Fri, 2013-06-28 at 18:40 +0100, Matthew Garrett wrote:
On Fri, Jun 28, 2013 at 10:13:15AM -0700, Adam Williamson wrote:
> Well, I'd say _limited_ compatibility. We've had all kinds of bugs in
> Mac support in, well, pretty much all previous releases too. It's not as
> if we have a track record of excellent support, we have a track record
> of 'you can probably kind of make it work if you try hard enough'.
Since F17 we've had a track record of "It'll work fine, as long as you
don't hit a kernel bug". Which is exactly where we are with every other
platform.
With all respect, the bug reports and blogs I've read would not lead me
to support that assertion.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
12:46 p.m.
On Fri, Jun 28, 2013 at 10:38 AM, Matthew Garrett <mjg59(a)srcf.ucam.org> wrote:
On Fri, Jun 28, 2013 at 01:26:52PM -0400, DJ Delorie wrote:
>
> If at 9:50am on release morning, aliens threatened to blow up the
> world if we shipped, we'd certainly do something about it.
>
> But it would be insane to expect us to *document* that we'd do
> something about it.
Why? "Beyond this point the release will only be delayed if an issue is
discovered that is deemed of exceptional importance" is a perfectly
reasonable thing to document.
Agreed. If added, and the end user demanded something unreasonable,
this would cover us and justify a delay.
1:04 p.m.
On Fri, 28 Jun 2013 10:46:51 -0700
Richard Vickery <richard.vickeryrv(a)gmail.com> wrote:
On Fri, Jun 28, 2013 at 10:38 AM, Matthew Garrett
<mjg59(a)srcf.ucam.org> wrote:
> On Fri, Jun 28, 2013 at 01:26:52PM -0400, DJ Delorie wrote:
>>
>> If at 9:50am on release morning, aliens threatened to blow up the
>> world if we shipped, we'd certainly do something about it.
>>
>> But it would be insane to expect us to *document* that we'd do
>> something about it.
>
> Why? "Beyond this point the release will only be delayed if an
> issue is discovered that is deemed of exceptional importance" is a
> perfectly reasonable thing to document.
>
Agreed. If added, and the end user demanded something unreasonable,
this would cover us and justify a delay.
Well, the problem is then someone would ask "What is exceptional" ?
So, we would need some process to determine that.
Based on this line you could also ask what we would do if some horrible
deadly bug was found _after_ public release. Should we remove images?
Disable mirrormanager? Repin the release? 19.1? 20?
Anyhow, if you would like to amend the release process, feel free to
write up a proposal.
kevin
1:11 p.m.
On Jun 28, 2013, at 10:26 AM, DJ Delorie <dj(a)redhat.com> wrote:
If at 9:50am on release morning, aliens threatened to blow up the
world if we shipped, we'd certainly do something about it.
So what you're saying is that you negotiate with terrorists? :-p
On a more serious note, though it hasn't been a focus before, dual boot is probably a
decent design goal for the next iteration. I'd probably not hold back this release at
this point in time, not that anybody asked me.
--Corey
1:14 p.m.
On 06/28/2013 01:31 PM, Stephen Gallagher wrote:
> Yee, I just _love_ me some Macs. Thanks; I'll take that into
> account for commonbugs. When did Macs stop having ethernet ports?
>
When the MacBook Air became the flagship Mac.
We just got a MacBook Air and it came with a Thunderbolt pigtail
Ethernet port:
http://cdn.arstechnica.net/wp-content/uploads/2012/06/tbge.jpg
1:21 p.m.
On Jun 28, 2013, at 10:39 AM, Peter Robinson <pbrobinson(a)gmail.com> wrote:
I don't think any of the thunderbolt equipped MBPs (or maybe the later
ones) have them. The thunderbolt ethernet adapters apparently work if
you plug them in before you power them on and presumably all the usb
ethernet adapters would work as an option.
To be slightly more specific as a Mac laptop user, all of their currently shipping laptops
omit an onboard Ethernet port, with the exception of their non-retina equipped MacBook
Pros. That specific line is widely considered to be legacy, and expected to be
discontinued.
--Corey
1:39 p.m.
On Jun 28, 2013, at 11:14 AM, Przemek Klosowski <przemek.klosowski(a)nist.gov> wrote:
On 06/28/2013 01:31 PM, Stephen Gallagher wrote:
>> Yee, I just _love_ me some Macs. Thanks; I'll take that into
>> account for commonbugs. When did Macs stop having ethernet ports?
>
> When the MacBook Air became the flagship Mac.
We just got a MacBook Air and it came with a Thunderbolt pigtail Ethernet port:
http://cdn.arstechnica.net/wp-content/uploads/2012/06/tbge.jpg
Those are ~$30 a pop, and don't ship with the laptop. Thus we can't count on a Mac
laptop user having one.
--Corey
3:13 p.m.
On Fri, Jun 28, 2013 at 6:00 PM, Matthew Garrett <mjg59(a)srcf.ucam.org> wrote:
and we have no history of producing updated
install images.
Is there *any* reason why we can't? This sounds like a reasonable
thing to do. Just because we have not done it in the past is not a
reason not to.
3:30 p.m.
On Fri, 2013-06-28 at 22:13 +0200, drago01 wrote:
On Fri, Jun 28, 2013 at 6:00 PM, Matthew Garrett
<mjg59(a)srcf.ucam.org> wrote:
> and we have no history of producing updated
> install images.
Is there *any* reason why we can't? This sounds like a reasonable
thing to do. Just because we have not done it in the past is not a
reason not to.
Well unless a bunch more people want to volunteer to test them, you'll
have a flaming-torch-and-pitchfork mob of QA people on your hands. =) We
already spend 8 months of the year on a constant test/rebuild/test
cycle; we get 2 months each cycle to do...pretty much everything else.
If we start trying to ship N.1 images we will likely be spending about 8
months of every 6 month cycle on release validation (if you see what I
mean). Count me out.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
3:32 p.m.
On Fri, 28 Jun 2013 22:14:51 +0200
drago01 <drago01(a)gmail.com> wrote:
On Fri, Jun 28, 2013 at 6:25 PM, Kevin Fenzi <kevin(a)scrye.com>
wrote:
> it makes sense from a logistic standpoint.
But from any other POV it makes no sense. There is no reason why we
cannot produce and ship updated images if we find a bug that is
important enough.
Sure, we could release every day given enough resources and desire to
do so.
I think we are very far afield. :)
kevin
3:36 p.m.
On Fri, Jun 28, 2013 at 10:32 PM, Kevin Fenzi <kevin(a)scrye.com> wrote:
On Fri, 28 Jun 2013 22:14:51 +0200
drago01 <drago01(a)gmail.com> wrote:
> On Fri, Jun 28, 2013 at 6:25 PM, Kevin Fenzi <kevin(a)scrye.com> wrote:
>
> > it makes sense from a logistic standpoint.
>
> But from any other POV it makes no sense. There is no reason why we
> cannot produce and ship updated images if we find a bug that is
> important enough.
Sure, we could release every day given enough resources and desire to
do so.
.... there is a difference between "every day" and "when there is an
urgent issue".
So this is really a non argument.
3:36 p.m.
On Fri, 28 Jun 2013 22:13:09 +0200
drago01 <drago01(a)gmail.com> wrote:
On Fri, Jun 28, 2013 at 6:00 PM, Matthew Garrett
<mjg59(a)srcf.ucam.org> wrote:
> and we have no history of producing updated
> install images.
Is there *any* reason why we can't? This sounds like a reasonable
thing to do. Just because we have not done it in the past is not a
reason not to.
Sure we could. We would need to:
* Have some way to freeze things so we could stablize for the release.
* Anaconda team willing to work on updated release + next release at
the same time.
* releng folks avilable to compose stuff.
* QA folks available to run through all the release tests.
* Mirrors willing to have another pile of release bits
* Marketing/press folks willing to put together stuff for the release
* Docs willing to update any release notes, etc.
* Any additional tooling needed if we call this 19.1 or something.
So, all this is doable, it's just a lot of resources to try and move
around, so personally I would only be willing to go down this road if
it was something really really really severe, and it would need buy in
from stakeholders.
kevin
3:43 p.m.
On Fri, Jun 28, 2013 at 10:36 PM, Kevin Fenzi <kevin(a)scrye.com> wrote:
On Fri, 28 Jun 2013 22:13:09 +0200
drago01 <drago01(a)gmail.com> wrote:
> On Fri, Jun 28, 2013 at 6:00 PM, Matthew Garrett
> <mjg59(a)srcf.ucam.org> wrote:
> > and we have no history of producing updated
> > install images.
>
> Is there *any* reason why we can't? This sounds like a reasonable
> thing to do. Just because we have not done it in the past is not a
> reason not to.
Sure we could. We would need to:
* Have some way to freeze things so we could stablize for the release.
We should use the GA package set + the fixed build not get all updates in.
It is to fix one bug not to create updated images.
* Anaconda team willing to work on updated release + next release at
the same time.
The anaconda team will have to fix the bug anyway. Unless the bug requires
lots of changes should be easy to backport (cherry-pick) assuming an
anaconda bug
is the reason why we need a release. Otherwise they don't have to do anything.
* releng folks avilable to compose stuff.
* QA folks available to run through all the release tests.
Both sound doable.
* Mirrors willing to have another pile of release bits
* Marketing/press folks willing to put together stuff for the release
* Docs willing to update any release notes, etc.
* Any additional tooling needed if we call this 19.1 or something.
Do we have to bump the release number? We can just update the images
and let mirrors resync.
So, all this is doable, it's just a lot of resources to try and
move
around,
Sure it needs work but do we should care about quality of what we ship
to users. If we fucked up
we should try to fix it. Not just say "sorry that happened see you 6-8 months".
so personally I would only be willing to go down this road if
it was something really really really severe,
That's the whole point. We should do it only if we have to. But not
rule it out "because we have never done that".
and it would need buy in from stakeholders.
Given that we don't point guns at people in a (mostly) volunteer
driven project ... this is a given.
4:09 p.m.
On 28 June 2013 14:43, drago01 <drago01(a)gmail.com> wrote:
On Fri, Jun 28, 2013 at 10:36 PM, Kevin Fenzi <kevin(a)scrye.com>
wrote:
> On Fri, 28 Jun 2013 22:13:09 +0200
> drago01 <drago01(a)gmail.com> wrote:
>
> * Mirrors willing to have another pile of release bits
> * Marketing/press folks willing to put together stuff for the release
> * Docs willing to update any release notes, etc.
> * Any additional tooling needed if we call this 19.1 or something.
Do we have to bump the release number? We can just update the images
and let mirrors resync.
In the far past when this was discussed, it was expensive for multiple
reasons:
1) Mirrors may not remirror static content. They do it once and then focus
on directories that they know change a lot. It cuts down their network
costs in a number of ways. So you end up with mirrors with one iso and
others with other isos.
2) People get a version of ISO x and then compare the MD5/signature with
the updated version and then start wondering if the website has been
hacked. Emails on this can show up years and years later when no one
remembers that the ISO was replaced for some reason. We still get requests
and people using Fedora Core 6 images they just got..
All of these end up costing more in time and electrons than just spinning
up updates.img or a .x version.
Not counting the usual fight that has happened in the past for "why isn't
my update not in the respin?" .. especially when some argument can be made
that it is causing some sort of installation issue from my icons aren't
right on this box to that selinux policy would help make out fo the box
experience better.
--
Stephen J Smoogen.
4:16 p.m.
On Fri, 2013-06-28 at 22:43 +0200, drago01 wrote:
On Fri, Jun 28, 2013 at 10:36 PM, Kevin Fenzi <kevin(a)scrye.com>
wrote:
> On Fri, 28 Jun 2013 22:13:09 +0200
> drago01 <drago01(a)gmail.com> wrote:
>
>> On Fri, Jun 28, 2013 at 6:00 PM, Matthew Garrett
>> <mjg59(a)srcf.ucam.org> wrote:
>> > and we have no history of producing updated
>> > install images.
>>
>> Is there *any* reason why we can't? This sounds like a reasonable
>> thing to do. Just because we have not done it in the past is not a
>> reason not to.
>
> Sure we could. We would need to:
>
> * Have some way to freeze things so we could stablize for the release.
We should use the GA package set + the fixed build not get all updates in.
It is to fix one bug not to create updated images.
I think there's some confusion here. You now actually seem to be talking
about the specific question of producing an updated install image one
time, for this one issue, but at first it seemed like you were
advocating it as The New Way Forward.
Assuming we find a single simple change that Fixes Mac UEFI Dual Boot in
anaconda, then from a purely technical standpoint, yes, we could
theoretically throw together a boot ISO and DVD with the fix in quite
easily. All it'd need would be a new build of anaconda with only that
fix, and someone to run pungi a couple of times.
Given the apparent constraints on network access on Macs it might even
make sense to do that in this particular case, if someone wants to spend
the time on it.
The way I'd envisage that happening, though, is that we stick them up
pretty unofficially with a 'this is an image we think might install
better on Macs, use it if you like' label on it. I definitely wouldn't
want to go around sounding trumpets and calling it Fedora 19.1.
Something altogether less official and more low key seems appropriate.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
4:42 p.m.
On Jun 28, 2013, at 10:39 AM, Matthew Garrett <mjg59(a)srcf.ucam.org> wrote:
On Fri, Jun 28, 2013 at 10:25:58AM -0600, Kevin Fenzi wrote:
> - Say we ground all the wheels to a halt and slipped for this bug.
> Where to do we draw the line? If someone comes up with a bug at
> 9:50am on release morning, do we cancel everything? There has to be a
> point where we say "sorry, it's too late" and this has been it since
> it makes sense from a logistic standpoint.
If at 9:50am on release morning we discovered that the installer would
format all connected drives if the month had two digits, I'd like to
think we'd do something about it. It's inevitably going to be a
judgement call based on the perceived harm in releasing as is against
the harm caused by slipping, just as it is at any other point in the
release process. Current policy effectively says "There is no issue
sufficient to delay release after we've said an image is good", and I
don't believe that that's true.
One possible solution is either more padding (time) between any RC release and go/no-go;
or if certain listed packages, like anaconda, pykickstart, blivet, etc. are touched in
even a seemingly trivial way, then the full QA test matrix has to be retested. Maybe
that's already implicitly the case, but I don't know if it's a rule.
But what definitely isn't the case is, Macs are still not officially supported by QA
for blocker status for Mac specific major bugs. If a Mac only bug comes up, block status
is rejected on the basis that too few people will experience the bug. So before I'd
suggest holding up Fedora 19, I think Macs need to have a promoted hardware status.
Something not totally dissimilar happened for Fedora 18 that was also a problem for Macs.
That's bug 893839 "Mac EFI from DVD and LiveCD ISO burned to actual DVD media
results in grub prompt, no boot". I didn't find that until final, definitely too
late.
But the final release series of RC's happen very quickly, and any allowed change is by
definition significant (i.e. necessary) or it simply wouldn't happen, but that also
makes the change higher risk than other changes. So I think more time padding is needed
between an RC and go/nogo.
Chris Murphy
5:10 p.m.
On Jun 28, 2013, at 11:39 AM, Peter Robinson <pbrobinson(a)gmail.com> wrote:
I don't think any of the thunderbolt equipped MBPs (or maybe the later
ones) have them. The thunderbolt ethernet adapters apparently work if
you plug them in before you power them on and presumably all the usb
ethernet adapters would work as an option.
I think the rule of thumb is if it has one Thunderbolt port and isn't an Air, it has
ethernet. If it has two Thunderbolt ports (starting with the late 2012 MBP models), they
don't have ethernet. I have a 2011 Thunderbolt MBP and it does have ethernet.
In any case the Air is sufficiently popular in and out of hard core Mac circles that
it'd need to be taken into account for common bugs.
Chris Murphy
5:20 p.m.
On Fri, 2013-06-28 at 15:42 -0600, Chris Murphy wrote:
But the final release series of RC's happen very quickly, and
any
allowed change is by definition significant (i.e. necessary) or it
simply wouldn't happen, but that also makes the change higher risk
than other changes. So I think more time padding is needed between an
RC and go/nogo.
I think you may be labouring under a bit of a misapprehension about what
should be tested, here. The distinction between a TC and an RC is not
large. An RC can only happen after freeze and must have all blockers
fixed: if a build after freeze doesn't have all blockers addressed, we
call it a TC.
We have gotten better at finding blockers earlier in recent releases.
What this means is that we're doing fewer but _better_ RCs. Back around
F14 or F15, our first 'RC' build was pretty much a joke; there was never
any chance it was actually going to get released. We'd find five
blockers in it straight away. I think in the last few release cycles,
though, we've actually released RC1 or RC2 several times.
I don't really see there being some big distinction between TCs and RCs.
If you want to make sure some workflow that's important to you is going
to work it's really a good idea to follow the process from TC1, there is
no mileage in jumping in at RC1, that's too late. (Never mind the people
who, every release, seem to jump in and start testing on the day we do
go/no-go and then kick up a fuss about whatever they find...not you, but
it does seem to happen).
That doesn't quite apply to this specific case, as it happens, but it's
an important point to make.
Getting down to specifics: the change that we believe broke this -
trying to re-use an existing EFI system partition if one is present
instead of always creating a new one - went into anaconda 19.30.10. TC6
had 19.30.9, RC1 had 19.30.11; 19.30.10 probably only went into smoke
test builds and we found some problem which necessitated 19.30.11. RC1
came out very early Tuesday morning (06-25) (2am Eastern time). If we
assume this had been a blocker bug (which I still think it probably
wasn't), that gave us about...62 hours to catch it before the sign-off
happened.
That is a pretty short timeframe, indeed. If we want to identify one
specific Thing That Went Wrong here, I would say it's that we probably
shouldn't have taken a moderately significant behaviour change as late
as that. So let's look at that in a bit more detail:
https://bugzilla.redhat.com/show_bug.cgi?id=974543 is the bug that
prompted this change. It was filed on 06-14 (though we'd been aware of
the behaviour for rather longer). It was proposed as a freeze exception
issue by bcl (anaconda developer) on 06-17: that effectively means
anaconda team was of the opinion that they wanted this change to go in.
It was reviewed for freeze exception status on 06-19. The log of the
review meeting is at
http://meetbot.fedoraproject.org/fedora-blocker-review/2013-06-19/f19fina...
. Here are the relevant bits extracted, since it's very short:
18:53:38 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=974543
18:54:20 <Viking-Ice> dances on the limit of blocker
18:56:37 <kparal> but we should definitely vote on 974543
18:56:48 <kparal> it's proposed and patches are ready
18:57:09 <adamw> +1 on 974543
18:57:20 <jreznik> +1 FE for 974543, seems like bcl wants this one
18:57:59 <tflink> #topic (974543) Anaconda is always creating new efi
system partition
18:58:02 <tflink> #link
https://bugzilla.redhat.com/show_bug.cgi?id=974543
18:58:04 <tflink> #info Proposed Freeze Exceptions, anaconda, NEW
18:58:10 <adamw> tflink: the patches are not sent to anaconda-devel-list
so technically not 'post'ed
18:58:11 <adamw> +1
18:58:20 <kparal> +1 FE
18:58:20 <adamw> this is completely wrong behaviour and ought to be
fixed
18:58:27 <nirik> +1 FE
18:58:31 <Viking-Ice> +1
18:58:35 <dgilmore> +1 FE
18:58:36 <jreznik> +1 FE
18:59:12 <adamw> shame to put it in this late, but otoh our 'multiboot
uefi' story has never worked very well so unlikely to maek things worse
18:59:32 <tflink> proposed #agreed 974543 - AcceptedFreezeException -
This behavior of creating new EFI partitions is not correct and should
be fixed. A tested fix would be considered past freeze
18:59:33 <adamw> at some point we're going to run into the problem of
what to do if there isn't enough space in the esp but we'll burn that
bridge when we get to it
18:59:33 <adamw> ack
18:59:49 <jreznik> ack
18:59:57 <nirik> ack
18:59:59 <Viking-Ice> ack
18:59:59 <tflink> #agreed 974543 - AcceptedFreezeException - This
behavior of creating new EFI partitions is not correct and should be
fixed. A tested fix would be considered past freeze
19:00:00 <handsome_pirate> ack
19:00:20 <kparal> adamw: the files are very small, currently
So it sailed through review with +1s from four QA folks (myself, Kamil,
Tim (implied) and Johann), one from releng (dgilmore) and one from the
program manager (jreznik). As has often been the case lately, no-one
outside of those groups bothered to show up for the meeting. It had an
implied +1 from the anaconda developers due to the fact that they had
proposed it in the first place: we put a fairly high weight on that fact
during review.
I very perfunctorily mentioned that it was somewhat dangerous to poke it
this late, but incorrectly (as it transpired) thought it was unlikely to
make things any worse; I'm pretty sure at the time I just did not think
of the possibility of anything like this bug arising.
The fix was committed to anaconda git one day later:
https://git.fedorahosted.org/cgit/anaconda.git/commit/?h=f19-branch&i...
committer David Lehman <dlehman(a)redhat.com> 2013-06-20 20:01:39 (GMT)
We usually have a second 'gate' on FE issues at the point of composing
an actual release image: the person requesting the compose (which is
usually me) and the person doing it (which is usually dgilmore) tend to
have a chat if either feels that it might now be too late to take one of
the FE fixes safely. But this unfortunately doesn't really apply to
anaconda changes, because they're basically a package deal. In a really
extraordinary case we can go to the anaconda devs and ask them to back
out a change we really don't want, but that's pretty rare and we didn't
consider it in this case. So effectively we were committed to taking
this change the moment it was committed to f19-branch in git.
It's kind of interesting that we didn't get a compose that included the
change for four days after that. Koji tells us that anaconda 19.30.10
was built Mon, 24 Jun 2013 21:50:49 UTC and 19.30.11 Mon, 24 Jun 2013
23:27:23 UTC, so a delay between .10 and .11 wasn't the problem. Instead
the delay was between the change being committed to git and a new
anaconda build happening at all - four days, which is quite a lot for
this late in the release cycle. But most of the explanation for that is
fairly mundane: the weekend. The commit was done in the middle of the
day on a Thursday. I don't recall why a build wasn't done on the Friday:
I think it may have been that we felt TC6 was a build we wanted to get a
full validation run done on, and we wanted the next build to be an RC,
and we had other blocker bugs to fix, so there wasn't felt to be any
urgency to get a new compose out for testing. But for whatever reason,
it wasn't. anaconda team does not work weekends, so the build happened
on the next work day, Monday, and the RC1 compose happened shortly
after.
So it's a bit hard to say that this or that party clearly made a
mistake, but I think it'd be reasonable to say that ultimately 'we' -
QA, releng, anaconda devs - may not have made the best call in deciding
to take that change at a point when we were pretty far along in
pre-release stabilization. But anaconda FEs are always a somewhat tricky
call, and there was a clear and substantial upside to this one (it's
really not right at all to go around creating new ESPs on systems that
already have them, and we were aware of cases where this just messed up
boot, possibly even of *other* OSes). So I don't think it was
egregiously the wrong decision. In practice it does not seem to have
turned out for the best, though.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
5:24 p.m.
On Fri, Jun 28, 2013 at 11:16 PM, Adam Williamson <awilliam(a)redhat.com> wrote:
On Fri, 2013-06-28 at 22:43 +0200, drago01 wrote:
> On Fri, Jun 28, 2013 at 10:36 PM, Kevin Fenzi <kevin(a)scrye.com> wrote:
> > On Fri, 28 Jun 2013 22:13:09 +0200
> > drago01 <drago01(a)gmail.com> wrote:
> >
> >> On Fri, Jun 28, 2013 at 6:00 PM, Matthew Garrett
> >> <mjg59(a)srcf.ucam.org> wrote:
> >> > and we have no history of producing updated
> >> > install images.
> >>
> >> Is there *any* reason why we can't? This sounds like a reasonable
> >> thing to do. Just because we have not done it in the past is not a
> >> reason not to.
> >
> > Sure we could. We would need to:
> >
> > * Have some way to freeze things so we could stablize for the release.
>
> We should use the GA package set + the fixed build not get all updates in.
> It is to fix one bug not to create updated images.
I think there's some confusion here. You now actually seem to be talking
about the specific question of producing an updated install image one
time, for this one issue, but at first it seemed like you were
advocating it as The New Way Forward.
What I am saying is that for this particalur issue we should do it
once we have a fix. It does not have to be 19.1 or any other fancy
thing just provide something.
*AND* leave this option open for future release i.e if we have found
an issue that should have been fixed before release and that cannot be
fixed by an update we
should consider doing this again (decide on case by case basis).
We should not rule it out just "because we have never done it".
5:27 p.m.
On Sat, 2013-06-29 at 00:24 +0200, drago01 wrote:
On Fri, Jun 28, 2013 at 11:16 PM, Adam Williamson
<awilliam(a)redhat.com> wrote:
> On Fri, 2013-06-28 at 22:43 +0200, drago01 wrote:
>> On Fri, Jun 28, 2013 at 10:36 PM, Kevin Fenzi <kevin(a)scrye.com> wrote:
>> > On Fri, 28 Jun 2013 22:13:09 +0200
>> > drago01 <drago01(a)gmail.com> wrote:
>> >
>> >> On Fri, Jun 28, 2013 at 6:00 PM, Matthew Garrett
>> >> <mjg59(a)srcf.ucam.org> wrote:
>> >> > and we have no history of producing updated
>> >> > install images.
>> >>
>> >> Is there *any* reason why we can't? This sounds like a reasonable
>> >> thing to do. Just because we have not done it in the past is not a
>> >> reason not to.
>> >
>> > Sure we could. We would need to:
>> >
>> > * Have some way to freeze things so we could stablize for the release.
>>
>> We should use the GA package set + the fixed build not get all updates in.
>> It is to fix one bug not to create updated images.
>
> I think there's some confusion here. You now actually seem to be talking
> about the specific question of producing an updated install image one
> time, for this one issue, but at first it seemed like you were
> advocating it as The New Way Forward.
What I am saying is that for this particalur issue we should do it
once we have a fix. It does not have to be 19.1 or any other fancy
thing just provide something.
*AND* leave this option open for future release i.e if we have found
an issue that should have been fixed before release and that cannot be
fixed by an update we
should consider doing this again (decide on case by case basis).
We should not rule it out just "because we have never done it".
What we rule out is doing big official .1 builds. We have done various
semi-official post-release workarounds for awkward bugs in the past,
along the lines of what we're discussing here. special boot.isos showing
up in people's fedorapeople.org directories are not unknown. updates.img
links in the commonbugs pages are fairly frequent.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
7:51 p.m.
On Jun 28, 2013, at 4:20 PM, Adam Williamson <awilliam(a)redhat.com> wrote:
I think you may be labouring under a bit of a misapprehension about what
should be tested, here. The distinction between a TC and an RC is not
large. An RC can only happen after freeze and must have all blockers
fixed: if a build after freeze doesn't have all blockers addressed, we
call it a TC.
The distinction between TC and RC is large in that an RC1 *could* be final release. And
since this particular bug wasn't in TC6 but was in the very next build, RC1, I think
that's consistent with suggesting more time between an RC and a go/no-go. I'm not
saying e.g. maybe there shouldn't be freeze exception fixes in RCs. Just a bit more
time when certain packages are touched.
Although even better than that would be more recruitment of Mac users to do installation
testing, so that it's possible to get installation tests done for at least RC1s. I
tested it in a VM, foolishly not testing it on baremetal. RC2 hit, and I missed that since
RC3 came soon after and immediately tested that on baremetal. But between RC3 and go/no-go
was a matter of hours.
Chris Murphy
7:56 p.m.
On 2013-06-28 17:51, Chris Murphy wrote:
On Jun 28, 2013, at 4:20 PM, Adam Williamson
<awilliam(a)redhat.com>
wrote:
>
> I think you may be labouring under a bit of a misapprehension about
> what
> should be tested, here. The distinction between a TC and an RC is not
> large. An RC can only happen after freeze and must have all blockers
> fixed: if a build after freeze doesn't have all blockers addressed, we
> call it a TC.
The distinction between TC and RC is large in that an RC1 *could* be
final release.
Yes, I did address that in the rest of the mail. I was making a general
point, not a specific one.
And since this particular bug wasn't in TC6 but was in
the very next build, RC1, I think that's consistent with suggesting
more time between an RC and a go/no-go.
If we do this, we are going to have more slips. _Considerably_ more
slips. That is the trade-off. I don't think it's one people will be
happy with. It's really that simple.
Although even better than that would be more recruitment of Mac
users
to do installation testing, so that it's possible to get installation
tests done for at least RC1s. I tested it in a VM, foolishly not
testing it on baremetal. RC2 hit, and I missed that since RC3 came
soon after and immediately tested that on baremetal. But between RC3
and go/no-go was a matter of hours.
Because RC3 was RC2 with a single very precise change; we were basically
expecting to be GO on RC2 when I went to sleep on Wednesday night, then
an issue was found just after I went to sleep, and we decided to go
ahead and just fix it and respin. The change was isolated in the
anaconda TUI interface's Software Selection spoke so really couldn't
possibly affect anything else.
We do actually have more than a few people with Macs: you, Fedora QA's
Brno team, mjg59, and I think someone on anaconda team has one. It would
be nice if at least one of the above could test each *C, though I
realize bare metal testing is a PITA and I hate it myself.
If we actually blocked on Mac dual boot by policy, we would have a test
case for it, and we would not have considered releasing without having
that test case run in at least one of the RCs, FWIW.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
8:06 p.m.
On Sex, 2013-06-28 at 14:16 -0700, Adam Williamson wrote:
On Fri, 2013-06-28 at 22:43 +0200, drago01 wrote:
> On Fri, Jun 28, 2013 at 10:36 PM, Kevin Fenzi <kevin(a)scrye.com> wrote:
> > On Fri, 28 Jun 2013 22:13:09 +0200
> > drago01 <drago01(a)gmail.com> wrote:
> >
> >> On Fri, Jun 28, 2013 at 6:00 PM, Matthew Garrett
> >> <mjg59(a)srcf.ucam.org> wrote:
> >> > and we have no history of producing updated
> >> > install images.
> >>
> >> Is there *any* reason why we can't? This sounds like a reasonable
> >> thing to do. Just because we have not done it in the past is not a
> >> reason not to.
> >
> > Sure we could. We would need to:
> >
> > * Have some way to freeze things so we could stablize for the release.
>
> We should use the GA package set + the fixed build not get all updates in.
> It is to fix one bug not to create updated images.
I think there's some confusion here. You now actually seem to be talking
about the specific question of producing an updated install image one
time, for this one issue, but at first it seemed like you were
advocating it as The New Way Forward.
Assuming we find a single simple change that Fixes Mac UEFI Dual Boot in
anaconda, then from a purely technical standpoint, yes, we could
theoretically throw together a boot ISO and DVD with the fix in quite
easily. All it'd need would be a new build of anaconda with only that
fix, and someone to run pungi a couple of times.
Given the apparent constraints on network access on Macs it might even
make sense to do that in this particular case, if someone wants to spend
the time on it.
The way I'd envisage that happening, though, is that we stick them up
pretty unofficially with a 'this is an image we think might install
better on Macs, use it if you like' label on it. I definitely wouldn't
want to go around sounding trumpets and calling it Fedora 19.1.
Something altogether less official and more low key seems appropriate.
I like the idea of 19.1 pretty unofficially or untested, which fix some
issues on mac installs. Which is basically someone run pungi with new
boot installer stuff.
Fedora installer already install updates, when we internet, if I'm not
wrong or at least in my install methods, so we don't need a 19.1 for
others things that aren't in boot process. And if some team fix and
release some packages that fix boots of any kind why not ?
Release 19.1 could be only directories releases/19.1/Fedora/$arch/iso
and releases/19.1/Fedora/$arch/os/EFI,images and isolinux , without all
packages .
--
Sérgio M. B.
8:08 p.m.
On 29/06/2013, at 7:12, Chris Murphy <lists(a)colorremedies.com> wrote:
On Jun 28, 2013, at 10:39 AM, Matthew Garrett <mjg59(a)srcf.ucam.org> wrote:
> On Fri, Jun 28, 2013 at 10:25:58AM -0600, Kevin Fenzi wrote:
>
>> - Say we ground all the wheels to a halt and slipped for this bug.
>> Where to do we draw the line? If someone comes up with a bug at
>> 9:50am on release morning, do we cancel everything? There has to be a
>> point where we say "sorry, it's too late" and this has been it
since
>> it makes sense from a logistic standpoint.
>
> If at 9:50am on release morning we discovered that the installer would
> format all connected drives if the month had two digits, I'd like to
> think we'd do something about it. It's inevitably going to be a
> judgement call based on the perceived harm in releasing as is against
> the harm caused by slipping, just as it is at any other point in the
> release process. Current policy effectively says "There is no issue
> sufficient to delay release after we've said an image is good", and I
> don't believe that that's true.
One possible solution is either more padding (time) between any RC release and go/no-go;
or if certain listed packages, like anaconda, pykickstart, blivet, etc. are touched in
even a seemingly trivial way, then the full QA test matrix has to be retested. Maybe
that's already implicitly the case, but I don't know if it's a rule.
But what definitely isn't the case is, Macs are still not officially supported by QA
for blocker status for Mac specific major bugs. If a Mac only bug comes up, block status
is rejected on the basis that too few people will experience the bug. So before I'd
suggest holding up Fedora 19, I think Macs need to have a promoted hardware status.
Something not totally dissimilar happened for Fedora 18 that was also a problem for Macs.
That's bug 893839 "Mac EFI from DVD and LiveCD ISO burned to actual DVD media
results in grub prompt, no boot". I didn't find that until final, definitely too
late.
But the final release series of RC's happen very quickly, and any allowed change is
by definition significant (i.e. necessary) or it simply wouldn't happen, but that also
makes the change higher risk than other changes. So I think more time padding is needed
between an RC and go/nogo.
Doesn't matter much : radeon macs get hit by
https://bugzilla.redhat.com/show_bug.cgi?id=975280 on all kernel 3.9. (no x, no plymouth,
black screen)
So fedora 19 is somewhat useless on some intel macs.
Sincerely,
William
8:33 p.m.
We do actually have more than a few people with Macs: you, Fedora QA's Brno team,
mjg59, and I think someone on anaconda team has one. It would be nice if at least one of
the above could test each *C, though I realize bare metal testing is a PITA and I hate it
myself.
I do bare metal testing on intel macs but more often than not i find bug reports around
the kernel are just flatly ignored, so I've kind of given up. Just my 2c
William
7:29 a.m.
On Sat, Jun 29, 2013 at 02:06:38 +0100,
Sérgio Basto <sergio(a)serjux.com> wrote:
I like the idea of 19.1 pretty unofficially or untested, which fix some
issues on mac installs. Which is basically someone run pungi with new
boot installer stuff.
The Unity guys used to do QA'd (by them) respins of Fedora. In those days
anaconda seemed to be a lot more sensitive to other package versions and
getting it to work in the respins was a bit of work.
11:05 a.m.
On Sat, 29 Jun 2013 02:06:38 +0100
Sérgio Basto <sergio(a)serjux.com> wrote:
I like the idea of 19.1 pretty unofficially or untested, which fix
some issues on mac installs. Which is basically someone run pungi
with new boot installer stuff.
We are currently pretty unsetup for any kind of point releases.
If someone wants to make some unofficial images, feel free.
Fedora installer already install updates, when we internet, if
I'm not
wrong or at least in my install methods, so we don't need a 19.1 for
others things that aren't in boot process. And if some team fix and
release some packages that fix boots of any kind why not ?
If it's unofficial, feel free.
Release 19.1 could be only directories releases/19.1/Fedora/$arch/iso
and releases/19.1/Fedora/$arch/os/EFI,images and isolinux , without
all packages .
No. If it's carried there and called 19.1 it's an official release of
the Fedora Project. In order for that to happen you would need to get
buy in from FESCo/qa/rel-eng, etc.
kevin
12:59 p.m.
On Sat, Jun 29, 2013 at 10:05:56AM -0600, Kevin Fenzi wrote:
> I like the idea of 19.1 pretty unofficially or untested, which
fix
> some issues on mac installs. Which is basically someone run pungi
> with new boot installer stuff.
We are currently pretty unsetup for any kind of point releases.
I think this is an interesting longer-term idea to consider, especially once
we have the idea of batching non-critical updates in place. That batch makes
a pretty good starting place for point releases.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
2:23 p.m.
On 2013-06-29 5:29, Bruno Wolff III wrote:
On Sat, Jun 29, 2013 at 02:06:38 +0100,
Sérgio Basto <sergio(a)serjux.com> wrote:
>
> I like the idea of 19.1 pretty unofficially or untested, which fix
> some
> issues on mac installs. Which is basically someone run pungi with new
> boot installer stuff.
The Unity guys used to do QA'd (by them) respins of Fedora. In those
days anaconda seemed to be a lot more sensitive to other package
versions and getting it to work in the respins was a bit of work.
If anything anaconda is more dependent on other packages than it used to
be these days. It no longer has its own 'first stage loader' (it uses
dracut since F17), it no longer does its own network configuration (it
uses NM), and there are other similar less large-scale changes that have
gone in in the last few releases. Taking more advantage of shared
components has been a focus of anaconda development since F16 or so.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
8:47 a.m.
On Sat, 2013-06-29 at 13:59 -0400, Matthew Miller wrote:
On Sat, Jun 29, 2013 at 10:05:56AM -0600, Kevin Fenzi wrote:
> > I like the idea of 19.1 pretty unofficially or untested, which fix
> > some issues on mac installs. Which is basically someone run pungi
> > with new boot installer stuff.
> We are currently pretty unsetup for any kind of point releases.
I think this is an interesting longer-term idea to consider, especially once
we have the idea of batching non-critical updates in place. That batch makes
a pretty good starting place for point releases.
We already have a pretty decent tool for tracking what goes into the GA
release:
https://qa.fedoraproject.org/blockerbugs/milestone/19/final/buglist
I have been thinking recently that it is a pity to just turn this off
once the GA comes, and let updates flow in unchecked. The tool could
easily be used to control what goes into a batched, qa-ed f19.1 update.
12:23 p.m.
On 2013-07-01 6:47, Matthias Clasen wrote:
On Sat, 2013-06-29 at 13:59 -0400, Matthew Miller wrote:
> On Sat, Jun 29, 2013 at 10:05:56AM -0600, Kevin Fenzi wrote:
> > > I like the idea of 19.1 pretty unofficially or untested, which fix
> > > some issues on mac installs. Which is basically someone run pungi
> > > with new boot installer stuff.
> > We are currently pretty unsetup for any kind of point releases.
>
> I think this is an interesting longer-term idea to consider,
> especially once
> we have the idea of batching non-critical updates in place. That batch
> makes
> a pretty good starting place for point releases.
We already have a pretty decent tool for tracking what goes into the GA
release:
https://qa.fedoraproject.org/blockerbugs/milestone/19/final/buglist
I have been thinking recently that it is a pity to just turn this off
once the GA comes, and let updates flow in unchecked. The tool could
easily be used to control what goes into a batched, qa-ed f19.1 update.
I am still wondering where the QA resources to do this are going to
magically spring from. Right now we have to deal with post-19 release
emergencies, test updates for 17, 18 and 19, and work on rather a lot of
improvements for the F20 cycle: we are trying to write Taskbot, we need
to revise the Final release criteria, update the entire validation test
case set, look over the Fedora 20 Change set to plan testing for
significant Changes, plan the F20 Test Day cycle, and then we go right
into F20 Alpha testing. Frankly, we are unlikely to achieve all of the
above, never mind somehow finding time to 'curate' an F19.1 release.
Grand plans are all very well, but they need to be based on a realistic
assessment of available resources.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
12:26 p.m.
On 07/02/2013 05:23 PM, Adam Williamson wrote:
>
I am still wondering where the QA resources to do this are going to
magically spring from. Right now we have to deal with post-19 release
emergencies, test updates for 17, 18 and 19, and work on rather a lot
of improvements for the F20 cycle: we are trying to write Taskbot, we
need to revise the Final release criteria, update the entire
validation test case set, look over the Fedora 20 Change set to plan
testing for significant Changes, plan the F20 Test Day cycle, and then
we go right into F20 Alpha testing. Frankly, we are unlikely to
achieve all of the above, never mind somehow finding time to 'curate'
an F19.1 release. Grand plans are all very well, but they need to be
based on a realistic assessment of available resources.
We could always enslave pony's ;)
JBG
12:38 p.m.
On 2013-07-02 10:26, Jóhann B. Guðmundsson wrote:
On 07/02/2013 05:23 PM, Adam Williamson wrote:
>>
>
> I am still wondering where the QA resources to do this are going to
> magically spring from. Right now we have to deal with post-19 release
> emergencies, test updates for 17, 18 and 19, and work on rather a lot
> of improvements for the F20 cycle: we are trying to write Taskbot, we
> need to revise the Final release criteria, update the entire
> validation test case set, look over the Fedora 20 Change set to plan
> testing for significant Changes, plan the F20 Test Day cycle, and then
> we go right into F20 Alpha testing. Frankly, we are unlikely to
> achieve all of the above, never mind somehow finding time to 'curate'
> an F19.1 release. Grand plans are all very well, but they need to be
> based on a realistic assessment of available resources.
We could always enslave pony's ;)
JBG
Yes! Intern unicorns! WHY DID I NOT THINK OF THIS BEFORE
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
3950
days inactive
3955
days old
50 comments
20 participants
participants (20)
-
Adam Williamson -
Bruno Wolff III -
Chris Murphy -
Corey Quinn -
DJ Delorie -
drago01 -
Jaroslav Reznik -
Josh Boyer -
Jóhann B. Guðmundsson -
Kevin Fenzi -
Matthew Garrett -
Matthew Miller -
Matthias Clasen -
Peter Robinson -
Przemek Klosowski -
Richard Vickery -
Stephen Gallagher -
Stephen John Smoogen -
Sérgio Basto -
William