subject:"Re\: Fedora 19 status is ALIVE, GA on July 02, 2013"


On 2013-06-28 17:51, Chris Murphy wrote:
On Jun 28, 2013, at 4:20 PM, Adam Williamson  
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
--
devel mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 19 status is ALIVE, GA on July 02, 2013

2013-06-28 Thread Chris Murphy

On Jun 28, 2013, at 4:20 PM, Adam Williamson  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
-- 
devel mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 19 status is ALIVE, GA on July 02, 2013

On Sat, 2013-06-29 at 00:24 +0200, drago01 wrote:
> On Fri, Jun 28, 2013 at 11:16 PM, 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  wrote:
> >> > On Fri, 28 Jun 2013 22:13:09 +0200
> >> > drago01  wrote:
> >> >
> >> >> On Fri, Jun 28, 2013 at 6:00 PM, Matthew Garrett
> >> >>  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

-- 
devel mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 19 status is ALIVE, GA on July 02, 2013

On Fri, Jun 28, 2013 at 11:16 PM, 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  wrote:
>> > On Fri, 28 Jun 2013 22:13:09 +0200
>> > drago01  wrote:
>> >
>> >> On Fri, Jun 28, 2013 at 6:00 PM, Matthew Garrett
>> >>  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".
-- 
devel mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 19 status is ALIVE, GA on July 02, 2013

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/f19final-blocker-review-7.2013-06-19-16.01.log.txt
. Here are the relevant bits extracted, since it's very short:

18:53:38 https://bugzilla.redhat.com/show_bug.cgi?id=974543
18:54:20 dances on the limit of blocker
18:56:37 but we should definitely vote on 974543
18:56:48 it's proposed and patches are ready
18:57:09 +1 on 974543
18:57:20 +1 FE for 974543, seems like bcl wants this one
18:57:59 #topic (974543) Anaconda is always creating new efi
system partition
18:58:02 #link
https://bugzilla.redhat.com/show_bug.cgi?id=974543
18:58:04 #info Proposed Freeze Exceptions, anaconda, NEW
18:58:10 tflink: the patches are not sent to anaconda-devel-list
so technically not 'post'ed
18:58:11 +1
18:58:20 +1 FE
18:58:20 this is completely wrong behaviour and ought to be
fixed
18:58:27 +1 FE
18:58:31 +1
18:58:35 +1 FE
18:58:36 +1 FE
18:59:12 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 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 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 ack
18:59:49 ack
18:59:57 ack
18:59:59 ack
18:59:59 #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 ack
19:00:20 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 hi

Re: Fedora 19 status is ALIVE, GA on July 02, 2013

2013-06-28 Thread Chris Murphy

On Jun 28, 2013, at 11:39 AM, Peter Robinson  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
-- 
devel mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 19 status is ALIVE, GA on July 02, 2013

2013-06-28 Thread Chris Murphy

On Jun 28, 2013, at 10:39 AM, Matthew Garrett  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
-- 
devel mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 19 status is ALIVE, GA on July 02, 2013

On Fri, 2013-06-28 at 22:43 +0200, drago01 wrote:
> On Fri, Jun 28, 2013 at 10:36 PM, Kevin Fenzi  wrote:
> > On Fri, 28 Jun 2013 22:13:09 +0200
> > drago01  wrote:
> >
> >> On Fri, Jun 28, 2013 at 6:00 PM, Matthew Garrett
> >>  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

-- 
devel mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 19 status is ALIVE, GA on July 02, 2013

2013-06-28 Thread Stephen John Smoogen

On 28 June 2013 14:43, drago01  wrote:

> On Fri, Jun 28, 2013 at 10:36 PM, Kevin Fenzi  wrote:
> > On Fri, 28 Jun 2013 22:13:09 +0200
> > drago01  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.
-- 
devel mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 19 status is ALIVE, GA on July 02, 2013

On Fri, Jun 28, 2013 at 10:36 PM, Kevin Fenzi  wrote:
> On Fri, 28 Jun 2013 22:13:09 +0200
> drago01  wrote:
>
>> On Fri, Jun 28, 2013 at 6:00 PM, Matthew Garrett
>>  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.
-- 
devel mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 19 status is ALIVE, GA on July 02, 2013

On Fri, 28 Jun 2013 22:13:09 +0200
drago01  wrote:

> On Fri, Jun 28, 2013 at 6:00 PM, Matthew Garrett
>  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

signature.asc
Description: PGP signature
-- 
devel mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 19 status is ALIVE, GA on July 02, 2013

On Fri, Jun 28, 2013 at 10:32 PM, Kevin Fenzi  wrote:
> On Fri, 28 Jun 2013 22:14:51 +0200
> drago01  wrote:
>
>> On Fri, Jun 28, 2013 at 6:25 PM, Kevin Fenzi  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.
-- 
devel mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 19 status is ALIVE, GA on July 02, 2013

On Fri, 28 Jun 2013 22:14:51 +0200
drago01  wrote:

> On Fri, Jun 28, 2013 at 6:25 PM, Kevin Fenzi  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


signature.asc
Description: PGP signature
-- 
devel mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 19 status is ALIVE, GA on July 02, 2013

On Fri, 2013-06-28 at 22:13 +0200, drago01 wrote:
> On Fri, Jun 28, 2013 at 6:00 PM, Matthew Garrett  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

-- 
devel mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 19 status is ALIVE, GA on July 02, 2013

On Fri, Jun 28, 2013 at 6:25 PM, Kevin Fenzi  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.
-- 
devel mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 19 status is ALIVE, GA on July 02, 2013

On Fri, Jun 28, 2013 at 6:00 PM, Matthew Garrett  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.
-- 
devel mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 19 status is ALIVE, GA on July 02, 2013

2013-06-28 Thread Corey Quinn



On Jun 28, 2013, at 11:14 AM, Przemek Klosowski  
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
-- 
devel mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 19 status is ALIVE, GA on July 02, 2013

2013-06-28 Thread Corey Quinn

On Jun 28, 2013, at 10:39 AM, Peter Robinson  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
-- 
devel mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 19 status is ALIVE, GA on July 02, 2013

2013-06-28 Thread DJ Delorie


> So what you're saying is that you negotiate with terrorists? :-p

"Anyone else want to negotiate?"

(sorry, couldn't resist ;)
-- 
devel mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 19 status is ALIVE, GA on July 02, 2013

2013-06-28 Thread Przemek Klosowski


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

--
devel mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 19 status is ALIVE, GA on July 02, 2013

2013-06-28 Thread Corey Quinn

On Jun 28, 2013, at 10:26 AM, 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.

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
-- 
devel mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 19 status is ALIVE, GA on July 02, 2013

On Fri, 28 Jun 2013 10:46:51 -0700
Richard Vickery  wrote:

> On Fri, Jun 28, 2013 at 10:38 AM, Matthew Garrett
>  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

signature.asc
Description: PGP signature
-- 
devel mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 19 status is ALIVE, GA on July 02, 2013

On Fri, Jun 28, 2013 at 10:43:33AM -0700, Adam Williamson wrote:

> With all respect, the bug reports and blogs I've read would not lead me
> to support that assertion.

With all respect, bug numbers.

-- 
Matthew Garrett | [email protected]
-- 
devel mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 19 status is ALIVE, GA on July 02, 2013

2013-06-28 Thread Richard Vickery

On Fri, Jun 28, 2013 at 10:38 AM, Matthew Garrett  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.
-- 
devel mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 19 status is ALIVE, GA on July 02, 2013

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

-- 
devel mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 19 status is ALIVE, GA on July 02, 2013

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 | [email protected]
-- 
devel mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 19 status is ALIVE, GA on July 02, 2013

2013-06-28 Thread Stephen Gallagher

-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 
  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-
-- 
devel mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 19 status is ALIVE, GA on July 02, 2013

2013-06-28 Thread Peter Robinson

On Fri, Jun 28, 2013 at 6: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
>> >>  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
-- 
devel mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 19 status is ALIVE, GA on July 02, 2013

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 | [email protected]
-- 
devel mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 19 status is ALIVE, GA on July 02, 2013

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

-- 
devel mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 19 status is ALIVE, GA on July 02, 2013

2013-06-28 Thread Josh Boyer

On Fri, Jun 28, 2013 at 1:31 PM, Stephen Gallagher  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
>>>  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
-- 
devel mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 19 status is ALIVE, GA on July 02, 2013

2013-06-28 Thread Stephen Gallagher

-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
>>  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-
-- 
devel mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 19 status is ALIVE, GA on July 02, 2013

2013-06-28 Thread DJ Delorie


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.
-- 
devel mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 19 status is ALIVE, GA on July 02, 2013

On Fri, 2013-06-28 at 13:19 -0400, Josh Boyer wrote:
> On Fri, Jun 28, 2013 at 1:13 PM, Adam Williamson  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

-- 
devel mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 19 status is ALIVE, GA on July 02, 2013

2013-06-28 Thread Josh Boyer

On Fri, Jun 28, 2013 at 1:13 PM, Adam Williamson  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
-- 
devel mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 19 status is ALIVE, GA on July 02, 2013

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

Re: Fedora 19 status is ALIVE, GA on July 02, 2013

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 | [email protected]
-- 
devel mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 19 status is ALIVE, GA on July 02, 2013

On Fri, 28 Jun 2013 17:00:40 +0100
Matthew Garrett  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


signature.asc
Description: PGP signature
-- 
devel mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora 19 status is ALIVE, GA on July 02, 2013