15:00:55 <adamw> #startmeeting Fedora QA meeting
15:00:55 <zodbot> Meeting started Mon Aug 27 15:00:55 2012 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:55 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:58 <adamw> #meetingname fedora-qa
15:00:58 <zodbot> The meeting name has been set to 'fedora-qa'
15:01:13 <adamw> morning, folks, who's here for some QA?
15:01:19 <adamw> #topic roll call
15:01:26 * tflink is here
15:01:48 * maxamillion is here
15:02:32 * spoore is here
15:02:38 * brunowolff is here for about 25 minutes
15:03:03 * nirik is lurking in the back
15:03:35 <adamw> alrighty
15:03:50 <adamw> #topic Incomplete anaconda functionality for Fedora 18
15:04:11 <adamw> so, in case anyone missed it, i filed a fesco ticket: https://fedorahosted.org/fesco/ticket/941
15:04:53 <adamw> anaconda team said that live install functionality will not be in place for alpha on current schedule, which is obviously an infraction of the release criteria
15:05:36 <tflink> the ticket was updated ~ 20 minutes ago to say that there is code, but it has had 0 testing and beta is a more realistic target
15:05:48 <adamw> i outlined the possible responses in terms of shipping Alpha in the ticket...for this meeting, the idea is to air the issue and see if we want to provide any input/recommendations as a team
15:06:35 <maxamillion> adamw: is there really any options or input/recommendations we can offer? if its not ready, its not ready .... its possible I'm misunderstanding, but I don't know that there's anything we can really do
15:06:37 <tflink> also that lmc is working and has been working for the most part (aside from a small window) to the best of bcl's knowledge but I don't think that's the issue right now for lives in composes
15:07:44 <adamw> maxam_: well, for instance, we could say we as a team feel as viking_ice does - that the release should get a substantial slip because anaconda's just not ready, and this is only one symptom of that
15:08:10 <maxamillion> ah
15:08:19 * nirik notes one more week slip puts us in US thanksgiving week.
15:08:26 <maxamillion> heh
15:08:33 <maxamillion> this should be good
15:08:53 <adamw> tflink: the issue is that it's not integrated into koji and usable by releng for doing official composes. you can run it, and produce a live image. but releng really want to be able to run it through koji, in a completely clean environment, for reproducibility.
15:09:15 <tflink> like I said, I don't think that lmc working or not is the issue ATM
15:09:23 <tflink> we haven
15:09:36 <adamw> maxamillion: or we could say that we don't think it's such a major issue, and we think we should go ahead on current schedule and ship non-installable lives
15:09:59 <tflink> we haven't touched the matrices much yet, I doubt that one more week is going to be enough at this point even if we decided to release alpha w/o live install
15:10:04 <adamw> maxamillion: that kind of thing...just do we, with whatever experience/wisdom we have as qa, have a strong feeling about which way fesco ought to jump on the question
15:10:07 <maxamillion> non-installable live images would completely negate the spins project
15:10:26 <maxamillion> I don't think that should be considered an option
15:10:41 <adamw> er, when i say 'ship', i mean for alpha; obviously the plan would still be for them to be installable at beta and final.
15:10:50 <maxamillion> ah
15:10:53 <brunowolff> I think for alpha just being able to run them live is enough. We don't even produce all of the live images for alpha and beta.
15:11:09 <tflink> even if we went the route of pushing off newui until F19, I wonder if all of the tooling would be updated fast enough to make that work this week
15:11:14 <maxamillion> ok, I misunderstood the impact
15:11:26 <tflink> not to mention the delay and extra work for the anaconda devs
15:12:19 <maxamillion> I don't think newui should be pushed off until F19, I think if anything that F18 just needs to be slipped further out .... but I'm not entirely convinced that's necessary
15:12:55 <adamw> tflink: yeah, i don't think 'go with oldui' is a good plan to keep us on the current schedule, but it's a possible 'cut the losses' plan if we think newui is just terminally not cooked yet and this problem is just one symptom
15:13:01 <brunowolff> How far are people willing to slip the F18 release for the new anaconda?
15:13:10 <adamw> i think johann's right in that we need to consider the wider question of newui's overall readiness here
15:13:12 <tflink> maxamillion: I still think that finishing the matrices this week is practical
15:13:23 <tflink> s/is/is not/
15:14:12 <maxamillion> I don't think that attempting to dictate a schedule or goal for the anaconda team is entirely realistic, wouldn't switching back to oldui for F18 be a considerable amount of work at this poitn?
15:14:16 <maxamillion> point*
15:14:25 <adamw> brunowolff: are you asking us for our opinions, or wondering how others outside qa would feel about that?
15:14:42 <brunowolff> Wondering more about outside people.
15:14:47 <adamw> maxam_: yes, it would. it's not a free action.
15:15:04 <maxamillion> adamw: your tab completion doesn't like me ;)
15:15:11 <adamw> heh
15:15:23 <maxamillion> adamw: my question to that would be "is the anaconda team even willing to do that?"
15:15:25 <tflink> maxamillion: I'm not familiar enough with the anaconda code for details, but I'd be surprised if it wasn't very expensive - at least a week delay if they went along with it
15:15:37 <brunowolff> I think in with defer anaconda we can probably guess how far we need to slip (probably 1-2 more weeks). If we try to stick with the newui, things seem a lot more unknown.
15:15:38 <adamw> maxamillion: if fesco told them to do that, they wouldn't have a choice, i guess...
15:16:12 <adamw> brunowolff: yeah, that's probably the most significant benefit of the oldui option.
15:17:42 <adamw> personally, i'm not a huge fan of the oldui idea, to be honest
15:17:56 <adamw> i do think that from a qa angle, the mandated slip option has a lot of things to like
15:18:24 <maxamillion> I'm not a fan of the oldui option either
15:18:25 <adamw> to me it feels like newui really is rather behind, and this isn't the only sticky problem we're likely to hit if we keep trying to keep to the schedule and doing one-week slips while we firefight
15:18:47 <tflink> if we go the mandated slip route, would we lift freeze for a bit?
15:18:57 <adamw> yeah, that's the key question with that option, what to do about the freeze
15:19:22 <adamw> if we lift it we introduce opportunities for instability, if we don't lift it then we're frozen for an awful long time and have a huge dump on unfreeze
15:19:30 * tflink is of the opinion that if we're slipping another 2-3 weeks, we should lift freeze for at least a week
15:19:38 <brunowolff> It would be nice for rawhide users to lift the freeze. Some updates don't get to rawhide otherwise.
15:19:42 <tflink> adamw: any more instability than we already have?
15:19:50 <adamw> the other option would be to pull certain big updates through the freeze - like gnome, for instance
15:19:54 <adamw> tflink: yeah.
15:20:35 <tflink> I guess I don't see much point in keeping the freeze that long since it would delay and frustrate other developers when we're going to be waiting a while for anaconda anyways
15:21:12 <tflink> so yes, it might introduce instability but avoiding said instability is going to come at a cost in frustration and annoyance from devs and possibly users
15:21:26 <tflink> is it worth holding everyone else back because we're waiting for anaconda?
15:21:40 <adamw> what's everyone else's feeling on the wider question? who's got alarm bells ringing about how well things will come out if we keep on the planned schedule, and who's relaxed?
15:22:17 <maxamillion> adamw: I don't like the idea of selectively pulling big updates like gnome through because you're going to have a slippery slope of upset folks who think their updates need in vs. others
15:22:19 <brunowolff> I also have some soname rebuilds waiting for a library update to clear testing. Probably some others are in this situation.
15:22:28 <adamw> maxamillion: yeah, that option could get political.
15:22:44 <adamw> see, this is the problem with qa, you're all too damn even-handed
15:22:46 <maxamillion> adamw: political/flamey
15:23:01 <maxamillion> lol
15:23:22 <brunowolff> I suggest talking to anaconda and get an estimate for when they can reasonably be ready for alpha and look at doing a multiweek slip to accommadate tham or falling back to the oldui.
15:23:24 <adamw> we should make fesco a recommendation that causes maximum inconvenience to developers and it's fesco's job to come up with a compromise that disappoints everyone! that's how rule by committee is meant to work!
15:23:32 <brunowolff> The final call there wouldn't be our decision.
15:24:12 <tflink> I think it depends on how hard we're pushing to get the matrices completed - I sincerely doubt that we're going to be ready with only 1 week more slip and I see little value in re-evaluating so often
15:24:40 <maxamillion> adamw: I think this is mostly a side effect of the fact that almost everyone here wears many hats and everyone tries to think about it from the viewpoints they have to entertain while wearing their non-qa hat ;)
15:24:47 <adamw> tflink: when you say 'completed'....we aren't required to run every test for alpha, just all the alpha-level tests
15:24:58 <maxamillion> s/hat/hats
15:24:58 <adamw> we try to do them all, but we can sign off on a release with just the 'alpha' tests completed
15:25:30 <tflink> true, still not convinced of the wisdom of slipping only one more week at this point
15:26:07 <tflink> if we keep freeze, 2 weeks might be enough. if we lift freeze, I bet it would be more like 3
15:26:28 <adamw> yeah, that was my thinking about that line too
15:26:57 <tflink> if we're going to lift freeze, we should do it soon
15:27:42 <adamw> so it sounds like no-one really feels strongly enough about any one option for us to come down as a team behind it and say 'this is what we recommend', but we can say there's some options we definitely don't like...does that sound like a reasonable summary?
15:27:44 <brunowolff> Is FESCO not meeting this week? It might be hard to get a quick response from them.
15:28:02 <adamw> brunowolff: yeah, LPC is a problem. they're discussing the issue in the ticket rather than meeting.
15:28:54 <tflink> adamw: I think that slipping week-by-week is a bad idea
15:28:58 <adamw> it sounds like we're not keen on going back to oldui, and though it would cause us as a team no problems, we're not too keen on a mandated slip without a freeze lift
15:28:58 <brunowolff> I think we can say we don't think one week is going to be enough whichever way we go with ananaconda.
15:29:21 <adamw> tflink: it sounds like, by elimination, you'd prefer to do a planned long slip with a freeze lift.
15:29:37 <brunowolff> There seems to be at least some sentiment amoung the group if we are going to slip 2+ weeks, we should have a short unfreeze period.
15:29:42 <adamw> yeah.
15:30:06 <tflink> adamw: planned longer slip - definitely. probably a freeze lift too but I don't feel as strongly about that part
15:30:09 <brunowolff> I need to go to a work meeting.
15:30:09 * nirik notes this gets us into december for release... unless we somehow shorten something else.
15:30:43 <tflink> I suppose we could just skip alpha altogether but I'm not sure that's a great idea
15:31:20 * nirik would not like that... if we wanted to think that way, a alpha with non installable live media would be much better.
15:31:22 * adamw trying to synthesize a list of recommendations for people to vote on
15:32:32 <tflink> adamw: split them up into separate items? revert to pre-newui, slip more than one week, lift freeze
15:32:40 <tflink> ?
15:32:42 <adamw> tflink: yeah, that's what i'm doing
15:33:27 <adamw> so far i've got this
15:33:33 <adamw> 1. We consider it unlikely Alpha will be releasable by the time of go/no-go on Aug 29/30.
15:33:36 <adamw> 2. We don't believe that reverting to oldUI is a great idea.
15:33:39 <adamw> 3. We are generally of the opinion that a planned slip longer than 2 weeks should be accompanied by a period where the release freeze is lifted.
15:34:22 <adamw> if those work, i'm wondering whether to add a '4. We favour the option of a 3 or more week slip with a 1 or more week freeze-lift period', or just leave it as-is, where that's more or less implied
15:34:32 <adamw> or if we should water it down a bit
15:34:39 <adamw> thoughts?
15:35:40 <tflink> how many of the anaconda devs are at LPC?
15:35:50 <adamw> my impression was basically everyone but jesse
15:35:56 <adamw> jesse said something about being left holding the can
15:36:30 <tflink> then I'd be more for the 3 or more week slip
15:36:40 <tflink> if they're mostly at LPC, I don't think this week counts
15:37:14 <maxamillion> +1
15:37:22 <tflink> which could possibly give releng enough time to get lmc working in koji
15:37:40 * adamw is clarifying in #anaconda at present
15:38:51 <nirik> well, part of the problem with lmc in koji is that it assumes you want to use libvirt and such... and it's 'script' interface doesn't work.
15:39:40 <adamw> okay, so lpc is not as much of a problem as we thought
15:39:50 <adamw> dcantrell, pjones and bcl are the ones out
15:41:35 <adamw> so in theory we can get builds this week; still, jkl appears to be still tracing out the consequences of that showstopper we've been stuck on for a week.
15:41:42 * nirik notes also that fesco doesn't meet this week, so we will need to push to get votes/action in ticket, which can sometimes be challenging. ;)
15:42:05 <nirik> so best case: 1 week slip probibly?
15:42:06 <adamw> it would be nice for fesco to make a decision by thursday, tbh.
15:42:29 <adamw> yeah, we're almost baking in another slip at this point, unless we all think the next anaconda build will be the magic one which hits all release criteria.
15:42:34 <adamw> if you believe that, i've got this bridge for sale...
15:43:13 * nirik nods
15:43:36 * tflink thinks that one more slip is a bit on the optimistic side
15:43:45 <tflink> but then again, I'm a bit of a cynic
15:43:53 <adamw> =)
15:44:09 <maxamillion> s/cynic/realist/
15:44:18 <adamw> i agree, but then, even if we do a planned slip at this point it doesn't rule out more slips at beta and final. we have issues with uncertainty here :/
15:44:23 <maxamillion> granted, they are basically synonyms these days
15:44:31 <adamw> does anyone want to take a shot at better recommendations than my three? or shall we just go with those?
15:44:59 <maxamillion> I'm good with those
15:45:02 <maxamillion> brb ... in dire need of more coffee
15:45:17 <tflink> I'm in favor of adding your #4
15:45:39 <tflink> I doubt that will be the option chosen, but it makes #3 seem less drastic
15:45:47 <adamw> hah. you're a politician too.
15:46:24 <tflink> in my experience, choosing release dates has more to do with politics than anything, anyways
15:46:26 <adamw> ok, let's make it all official, two parts seems like it'd be best
15:46:44 <adamw> first: propose #agreed we submit the three recommendations drafted above to the fesco ticket
15:46:53 <adamw> vote!
15:46:59 <tflink> what about the 4th?
15:47:22 <adamw> that's the second proposal
15:47:30 <adamw> i figured this one will go through easy, it's just a prelim
15:47:34 <adamw> then we vote on taking the 4th =)
15:47:47 <tflink> ok, just checking before voting
15:47:49 <tflink> +1
15:48:31 <adamw> who else is alive
15:49:04 <tflink> brno folks are away until wed
15:49:16 <tflink> I think we lost everyone else, too
15:49:19 <tflink> :(
15:49:25 <adamw> nirik was still soldiering on until two minutes ago
15:49:34 <tflink> I think that maxamillion will be back in a minute or so
15:49:37 <adamw> but i guess he finally couldn't take the qa jungle heat any mor
15:49:38 <adamw> e
15:49:41 <tflink> he said something about coffee
15:49:42 <nirik> ha.
15:49:45 <adamw> speaking of...
15:50:23 <nirik> I think your 1-3 are reasonable...
15:50:32 <adamw> ok, so that's a +1
15:50:35 <tflink> one of the other interesting side effects of a long slip is the time between F18 and F19
15:50:41 * adamw waits for maxam
15:50:44 <nirik> tflink: yep.
15:50:54 <adamw> yeah, i don't think we have to consider all those implications though, that's a fesco/board job i guess.
15:50:58 <nirik> the next cycle will need to be shorter, or move our 'traditional' dates.
15:51:26 <maxamillion> back
15:51:35 <adamw> got a vote on proposal #1?
15:52:00 <maxamillion> +1
15:52:05 <adamw> ok
15:52:13 <adamw> #agreed we submit the three recommendations drafted above to the fesco ticket
15:52:32 <tflink> adamw: you might want to #info those so that they show up in minutes
15:52:33 <adamw> propose #agreed we submit the proposed fourth recommendation, moderately in favour of a longer slip with a freeze lift
15:52:46 <adamw> tflink: oh yeah.
15:52:55 <tflink> probably before the agreed
15:52:59 <adamw> #undo
15:52:59 <zodbot> Removing item from minutes: <MeetBot.items.Agreed object at 0x1a36cf90>
15:53:13 <adamw> #info for the record, the recommendations are:
15:53:25 <adamw> #info 1. We consider it unlikely Alpha will be releasable by the time of go/no-go on Aug 29/30.
15:53:32 <adamw> #info 2. We don't believe that reverting to oldUI is a great idea.
15:53:44 <adamw> #info 3. We are generally of the opinion that a planned slip longer than 2 weeks should be accompanied by a period where the release freeze is lifted.
15:53:52 <adamw> #agreed we submit the three recommendations drafted above to the fesco ticket
15:54:02 * rbergeron also notes we are running into holidays, etc., particularly thxgiving in the us ... sorry to just drop in
15:54:26 <adamw> propose #agreed we submit the proposed fourth recommendation: "4. We favour the option of a 3 or more week slip with a 1 or more week freeze-lift period"
15:54:33 <tflink> +1
15:54:38 <adamw> rbergeron: i mostly think that's for fesco to consider rather than us
15:54:44 <maxamillion> +1
15:54:44 * rbergeron nods
15:54:47 <nirik> rbergeron: one week slip gets us in thanksgiving week. More than that gets into december
15:54:53 <rbergeron> yep
15:54:56 <adamw> we're not deciding the issue, just providing an official qa recommendations
15:55:04 <adamw> recommendation*
15:55:05 <maxamillion> Fedora: X-Mas Edition ... >.>
15:55:06 <tflink> assuming that we don't slip for beta or final, either
15:55:08 <maxamillion> errr
15:55:11 <maxamillion> Fedora: Winter Edititon
15:55:14 <rbergeron> tflink: hahahahahaha
15:55:18 <rbergeron> :D
15:55:20 <adamw> Winter Solstice Edition
15:55:24 <maxamillion> :)
15:55:28 * tflink has visions of a spherical cow w/ a santa hat in his head
15:55:36 <tflink> s/his/its/
15:55:44 <rbergeron> and a gift containing a snake
15:55:44 <maxamillion> that would be *awesome*
15:55:45 <adamw> nirik: what's your feeling?
15:56:06 <nirik> I'm not sure I favor that personally. ;)
15:56:30 <adamw> the recommendation, the santa hat, the snake, or all three? :)
15:56:31 <tflink> I'm not sure I like the idea, either. I just think it's the best option at this point
15:56:42 <nirik> if we could do 1 or 2 weeks slip, IMHO I would find that better...
15:56:52 <nirik> but not sure how likely that will be
15:57:49 <maxamillion> suppose that depends on how likely you are to accept that miracles are a reality
15:57:51 <adamw> so that feels like 2 +1s and a -0.5
15:58:07 <adamw> probably not strong enough to pass on such a strong point as representing the team
15:58:20 <tflink> we're missing a lot of people, too
15:58:30 <adamw> of course, the +1s could state their personal opinions in the ticket. so maybe we should just go with that.
15:59:31 <adamw> ok, are we all talked out or does anyone want to kick the can some more before we go into good ol' blocker review mode
15:59:32 <adamw> ?
15:59:47 <tflink> or wait until we have more people before suggesting #4?
16:00:05 <adamw> i don't think any more people are going to show up to this meeting
16:00:05 <tflink> that'll take me a minute to get ready. I'm not sure why it keeps catching me by surprise
16:00:22 <tflink> I didn't mean at the meeting
16:00:27 <rbergeron> does the anaconda team have a fairly firmed up list of "what's left" at this point?
16:00:31 <adamw> we could always bring it up again next week if the ticket is still open, but that would be a problem in itself
16:00:36 <adamw> tflink: i can float it on the list for sure,
16:00:54 <adamw> rbergeron: i'm not sure they have an official one, that's one thing jreznik is pushing for, which i'd agree with
16:01:13 <adamw> the next big pain point is the upgrade code, i suspect.
16:01:34 <adamw> that will likely be our big ass-kicker at beta point.
16:02:06 <adamw> #action adamw to float proposed recommendation #4 on the mailing list and add it to the ticket if it gets sufficient support
16:02:34 <rbergeron> me too, just to be more specific about what other milestones are, how likely those are... seems silly to delay for one aspect of the feature if the rest will also turn into need-another-2-weeks :/
16:02:42 * rbergeron shuts up now :D
16:03:12 <adamw> rbergeron: fesco should definitely consider that if they plump for the planned slip option, yeah. we would definitely want to try and make it the only slip, that would be the idea.
16:03:24 <adamw> so try and pin anaconda team down to how far behind they are and how much time they need to be really on top of things.
16:03:37 <tflink> include upgrade code, too
16:03:43 * tflink wasn't thinking about that yet
16:03:55 <adamw> i'd ideally want the slip to be long enough that they would have all the required features *written* by the end of the slip, and we'd be spending the rest of the cycle just testing them, as it should be.
16:04:03 <rbergeron> adamw: and if you guys have concerns re: any other specific aspects of testing - that is useful to have in the ticket
16:04:05 <adamw> this whole 'writing the code as we validate it' thing is not working out too well. =)
16:04:25 <rbergeron> i would think anyway
16:04:31 <adamw> rbergeron: roger
16:04:33 * rbergeron = not in fesco obviously
16:04:36 <rbergeron> :D
16:04:40 <adamw> but your very word is law
16:04:43 <adamw> LAW
16:05:12 <rbergeron> lame and womanly? large and waffles?
16:05:23 * rbergeron hangs out for blockers
16:05:28 <tflink> your very word is waffles?
16:05:37 <tflink> not sure what that means :)
16:05:38 <adamw> oh, should we throw in a different #4 - that we agree with jaroslav that it would be a really good idea to get a specific list from anaconda team of what's written, what still needs writing, and what isn't going to be written?
16:06:05 <adamw> or is that too much fiddling?
16:06:10 <adamw> probably not necessary....
16:06:22 <adamw> okay, ignore me. let's blocker review.
16:06:26 <rbergeron> i think nobody will disagree :D
16:06:37 <tflink> I think it would be nice to see
16:06:47 <adamw> #topic Fedora 18 Alpha mini blocker review
16:06:56 <adamw> tflink: i'll just throw it in as 'deep background', easier that way.
16:07:13 <tflink> adamw: can you #chair me?
16:07:25 <adamw> #chair tflink
16:07:25 <zodbot> Current chairs: adamw tflink
16:07:29 <adamw> #chair rbergeron
16:07:29 <zodbot> Current chairs: adamw rbergeron tflink
16:07:45 * tflink is planning to just do the proposed blockers and NTH today
16:07:55 <tflink> #info 8 Proposed Blockers
16:08:04 <tflink> #info 2 Proposed NTH
16:08:09 <adamw> yeah, we're over time already
16:08:10 <tflink> starting with the proposed blockers ...
16:08:16 <adamw> we'll probably have to move into -1, unless we're quick.
16:08:28 <tflink> fesco isn't meeting today
16:08:32 <tflink> #topic (851212) error: cannot invoke setopt() - perform() is currently running
16:08:35 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=851212
16:08:37 <tflink> #info Proposed Blockers, POST
16:09:11 <adamw> oh right, it's fesco that always kicks us out.
16:10:13 <tflink> I'm not sure about blocker on this but +1 nth
16:10:31 <adamw> well, a crash at the language selection screen is bad news
16:10:36 <tflink> true
16:10:44 <tflink> but is an intermittant crash a blocker for alpha?
16:11:03 <adamw> yeah, probably needs more data
16:11:15 <adamw> if other people start hitting it then i'd be +1
16:11:20 <adamw> +1 nth for sure
16:11:30 <adamw> are you -1 blocker or punt?
16:11:47 <rbergeron> nth/more data
16:11:50 <tflink> sounds like #851207 might be masking more occurances, though
16:11:53 <tflink> punt
16:12:26 <adamw> roger
16:12:28 <adamw> hi andre
16:12:32 <adamw> we're just cranking up blocker review
16:12:44 <adamw> i'm fine with accept as NTH, punt on blocker
16:13:13 <tflink> proposed #agreed 851212 - AcceptedNTH - This sounds kind of nasty but we need more data on how often it happens before deciding on blocker status for F18 alpha. More crashes could be masked by #851207.
16:13:20 <rbergeron> +1
16:13:20 <tflink> ack/nak/patch?
16:13:54 <adamw> ack
16:14:17 <aspratyush> ack
16:14:20 <tflink> #agreed 851212 - AcceptedNTH - This sounds kind of nasty but we need more data on how often it happens before deciding on blocker status for F18 alpha. More crashes could be masked by #851207.
16:14:31 <tflink> #topic (851220) EFI syslinux contains wrong path to kernel pair
16:14:32 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=851220
16:14:32 <tflink> #info Proposed Blockers, ASSIGNED
16:15:31 <rbergeron> multibug :D
16:16:10 <tflink> +1 blocker
16:16:29 <mjg59> Entertainingly mistitled
16:17:02 <tflink> proposed #agreed 851220 - AcceptedBlocker - Violates the following F18 alpha release criteria for EFI systems: "The installer must boot (if appropriate) and run on all primary architectures, with all system firmware types that are common on those architectures, from default live image, DVD, and boot.iso install media when written to an optical disc and when written to a USB stick with at least one of the officially supported methods"
16:17:06 <adamw> ack
16:17:08 <tflink> I bet that's too long, again
16:17:15 <adamw> nope, that one made it.
16:17:25 <nirik> ack
16:17:27 <tflink> cool, I should really figure out the max chars that can be in one line
16:18:11 <rbergeron> 510
16:18:40 <rbergeron> can vary by server though also :D
16:18:44 <rbergeron> ack
16:18:46 <tflink> #agreed 851220 - AcceptedBlocker - Violates the following F18 alpha release criteria for EFI systems: "The installer must boot (if appropriate) and run on all primary architectures, with all system firmware types that are common on those architectures, from default live image, DVD, and boot.iso install media when written to an optical disc and when written to a USB stick with at least one of the officially supported methods"
16:18:55 <tflink> rbergeron: sounds like you've hit this in the past :)
16:19:02 <tflink> the # of chars thing, I mean
16:19:13 <rbergeron> tflink: yes, but google is also awesome
16:19:15 <tflink> #topic (849982) The default Fedora 18 artwork refers to the previous release in F18 Alpha TC3
16:19:18 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=849982
16:19:20 <tflink> #info Proposed Blockers, NEW
16:19:36 <tflink> rbergeron: you mean that I should have googled for the answer to my question? That sounds like too much work :)
16:19:44 <adamw> oh, right, we punted this to talk to design team. then, er, did anyone talk to design team?
16:19:47 <adamw> i didn't. oops.
16:20:11 <tflink> yeah, I was wondering about that too
16:20:15 <tflink> punt until wed?
16:20:36 <tflink> AFAIK, we still don't have an installable gnome DE
16:21:01 <adamw> re-punt, if no-one got new info.
16:21:46 <tflink> #info still waiting on information on or conversation with artwork/design team, will re-evaluate at next blocker meeting if new information is available
16:22:04 <tflink> #topic (851207) DBusException: org.freedesktop.DBus.Error.UnknownMethod: Method "Get" with signature "ss" on interface "org.freedesktop.DBus.Properties" doesn't exist
16:22:07 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=851207
16:22:09 <tflink> #info Proposed Blockers, NEW
16:23:01 <tflink> this sounds like blocker for me
16:23:14 <adamw> how does it differ from 851212?
16:23:21 <adamw> just cos he saw this one twice? :)
16:23:49 <tflink> sounds like a lock versus wrong method issue
16:23:52 <tflink> to me, at least
16:24:14 <tflink> wrong method/improper call
16:24:25 <adamw> oh, man, you're going to get all technical on me?!
16:24:38 <adamw> ok, seriously, fair point
16:25:01 <tflink> "The installer must be able to complete package installation with the default package set for each supported installation method"?
16:25:03 <adamw> ah, more ipv6 stuff, looks like
16:25:08 <adamw> from the tb anyhow
16:25:10 <rbergeron> adamw: maybe he would have seen it a third time if he hadn't hit 851212?
16:25:17 <adamw> pick a criterion. that one works.
16:25:22 <adamw> rbergeron: yeah, it kinda looks that way.
16:25:54 * rbergeron suspects kamil might just be underscoring the fact that workaround isn't an option
16:25:55 <tflink> proposed #agreed 851207 - AcceptedBlocker - Violates the following F18 alpha release criterion: "The installer must be able to complete package installation with the default package set for each supported installation method"
16:26:06 <adamw> ack
16:26:23 <rbergeron> ack
16:27:18 <tflink> #agreed 851207 - AcceptedBlocker - Violates the following F18 alpha release criterion: "The installer must be able to complete package installation with the default package set for each supported installation method"
16:27:37 <tflink> #topic (851295) splitsep doesn't correctly handle variables with escaped spaces
16:27:40 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=851295
16:27:43 <tflink> #info Proposed Blockers, MODIFIED
16:28:16 <tflink> pretty clear blocker
16:28:49 <tflink> proposed #agreed 851295 - AcceptedBlocker - Violates the following F18 alpha release criterion for USB media: "The installer must boot (if appropriate) and run on all primary architectures, with all system firmware types that are common on those architectures, from default live image, DVD, and boot.iso install media when written to an optical disc and when written to a USB stick with at least one of the officially supported methods"
16:28:50 <adamw> it'd help to have a less cryptic explanation of this, in a way, but it does sound like it can break lots of things
16:29:02 <tflink> I think it breaks USB media mostly
16:29:30 <adamw> if it does in fact break usb i'm happy with that criterion
16:29:52 <tflink> IIRC, litd specifies stage2 which doesn
16:29:59 <tflink> t work when the path gets mangled
16:30:11 <adamw> i thought at present litd wasn't appending any parameters
16:30:13 <adamw> but imbw there
16:30:32 <tflink> makes 2 of us, I could easily be wrong on my understanding
16:30:49 <adamw> meh, we're way behind anyhow
16:30:56 <adamw> let's just take it on that basis and we can modify later if needs be.
16:30:57 <tflink> but I suppose that it would break network isntalls if it doesn't break USB
16:31:01 <adamw> ack then
16:31:10 <adamw> yeah, it's really just a case of which criterion we go for.
16:31:24 <adamw> although, that might make it beta. eh.
16:31:31 <tflink> #agreed 851295 - AcceptedBlocker - Violates the following F18 alpha release criterion for USB media: "The installer must boot (if appropriate) and run on all primary architectures, with all system firmware types that are common on those architectures, from default live image, DVD, and boot.iso install media when written to an optical disc and when written to a USB stick with at least one of the officially supported methods"
16:31:50 <tflink> I thought that we needed at least 1 of ftp/http at alpha
16:32:03 <tflink> nvm, different wording
16:32:12 <adamw> well it'd only be a problem if you specify a repo on the kernel command line, aiui.
16:32:17 <adamw> not if you do it interactively.
16:32:25 <tflink> yeah, it's more of a PXE issue
16:32:25 <adamw> oh well, move on!
16:32:27 <tflink> yep
16:32:45 <tflink> #topic (851274) Traceback during install - mount: /dev/sr0 is already mounted or /run/install/repo busy
16:32:45 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=851274
16:32:47 <tflink> #info Proposed Blockers, ASSIGNED
16:33:13 <adamw> we never acked this yet?
16:33:19 <adamw> well, +1, obviously.
16:33:24 <tflink> yep, same here
16:33:33 <tflink> "The installer must be able to complete package installation with the default package set for each supported installation method"?
16:33:59 * jreznik is reading backlog
16:34:28 <tflink> proposed #agreed 851274 - AcceptedBlocker - Violates the following F18 alpha release criterion for netinstall images: "The installer must be able to complete package installation with the default package set for each supported installation method"
16:34:32 <tflink> ack/nak/patch?
16:34:59 <adamw> ack
16:35:38 <tflink> #agreed 851274 - AcceptedBlocker - Violates the following F18 alpha release criterion for netinstall images: "The installer must be able to complete package installation with the default package set for each supported installation method"
16:36:06 <tflink> #topic (851500) UEFI boot: failure reading sector 0x40 from `cd0'.
16:36:06 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=851500
16:36:06 <tflink> #info Proposed Blockers, NEW
16:37:05 <tflink> hrm, not sure there's enough info here yet
16:37:16 <tflink> the later comments make it sound like a bit of an obscure problem
16:38:05 <adamw> yeah, i'm -0.5 on this
16:38:24 <tflink> I guess the question comes down to punt or reject?
16:38:42 <adamw> i think reject and ask him to file the kernel panic
16:38:59 <mjg59> I've got a patch for 851500
16:39:13 <mjg59> Ah, it's even uploaded already
16:39:28 <adamw> mjg59: are the 'failure reading' error message and the kernel panic connected?
16:39:33 <mjg59> Yes
16:39:33 <adamw> that's the key question here
16:39:40 <mjg59> The kernel panics because there's no initramfs
16:39:43 <adamw> ah, that makes it much more +1.
16:39:59 <adamw> definitely +1 nth
16:40:01 <mjg59> pjones uploaded the patch on August 15th
16:40:09 * rbergeron is nth here as well
16:40:12 <adamw> mjg59: how common is the issue likely to be? is it specific to a model, a firmware or what?
16:40:13 <mjg59> So should just need a newer grub2-efi tagged in
16:40:25 <mjg59> adamw: It's a timing issue. Depends on how good your CD drive is.
16:40:35 <mjg59> Short version: Intel can't write code for shit
16:41:03 <mjg59> Their ahci driver times out when doing large reads from slow media. Like the 20MB initramfs off a CD.
16:41:38 <adamw> so you need to be on an intel ahci system (but that's...a lot of systems), in uefi mode, with a not-too-great cd drive. the t420 apparently meets those criteria and is reasonably common, i guess.
16:41:55 <mjg59> We were hitting it on about 20% of tested systems
16:41:55 <adamw> mjg59: i don't see this issue referenced in the grub2 changelog anywhere
16:42:05 <mjg59> c1a25d07e636b5164c7ae225fbd395baed464af5
16:42:06 <adamw> is the patch definitely in the f18 grub2 tree?
16:42:12 <mjg59> "Work around AHCI firmware bug in efidisk driver"
16:42:17 <jreznik> 20% seems quite a lot for me
16:42:48 <mjg59> adamw: Seems to be here
16:42:52 <adamw> ah, k
16:43:15 <tflink> is 20% enough for blocker?
16:43:20 * tflink is on the fence
16:43:22 <adamw> 20% of uefi installs
16:43:31 <tflink> definitely +1 NTH, not so sure about blocker yet
16:43:36 <mjg59> Like I said, the bug is fixed, just needs to be tagged
16:43:44 <adamw> right, so it's pretty academic
16:43:46 <jreznik> how many people do we expect to use uefi?
16:43:56 <adamw> jreznik: quite small atm.
16:43:57 <tflink> in a fantasy world or in reality?
16:44:00 <mjg59> Enough that you've already flagged some UEFI-specific bugs as blockers
16:44:00 <adamw> but getting ever bigger.
16:44:52 <tflink> I'm going to go with +1 nth, -1 blocker
16:45:06 <tflink> there are acceptable workarounds (USB) and it only hits 20% of systems
16:45:16 <adamw> yeah, agreed
16:45:28 <adamw> mjg59: don't worry, this is just bureaucracy, either way the fix goes in.
16:45:36 <adamw> in fact it'd be going in anyway as we're already pulling that update for another nth issue.
16:45:42 <adamw> so just #agreed it and let's move on =)
16:45:48 * rbergeron puts up +1 nth in her window with pretty red tape
16:45:50 <jreznik> okm +1
16:46:02 * adamw just wanted to check the 'fix' didn't go into tc3 already and hence it wasn't working
16:46:06 <jreznik> rbergeron: blue one here!
16:46:13 <adamw> i kinda thought we had -5 in tc3. but i was wrong, it's slated for tc4.
16:46:20 <tflink> proposed #agreed 851500 - RejectedBlocker AcceptedNTH - This does affect the booting of the installer on ~ 20% of UEFI systems but only with optical media. Since USB is an acceptable workaround, accepting as NTH, rejecting as blocker
16:46:21 <rbergeron> jreznik: mine was for the red tape of bureaucracy ;)
16:46:23 <adamw> ack
16:46:36 <adamw> well, usb would be an acceptable workaround if *it* worked =)
16:47:13 <tflink> details ...
16:47:27 <tflink> other ack/nak/patch?
16:48:14 <adamw> i think we have implied acks...
16:48:20 <mjg59> adamw: USB should work for dded media, just not litd
16:48:37 <tflink> #agreed 851500 - RejectedBlocker AcceptedNTH - This does affect the booting of the installer on ~ 20% of UEFI systems but only with optical media. Since USB is an acceptable workaround, accepting as NTH, rejecting as blocker
16:48:55 <tflink> #topic (849389) uefi boot fails on Asus motherboards
16:48:55 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=849389
16:48:55 <tflink> #info Proposed Blockers, ON_QA
16:49:20 <mjg59> This should be fixed in the kernel, again just needs tagging
16:50:08 <adamw> seems to affect quite a lot of systems
16:50:12 <tflink> sounds like a blocker to me
16:50:12 <adamw> and less workaroundable than the last one
16:50:14 <adamw> +1 blocker for me too
16:51:05 <tflink> proposed #agreed 849389 - AcceptedBlocker - Violates the following F18 alpha release criterion for UEFI systems: "The installer must boot (if appropriate) and run on all primary architectures, with all system firmware types that are common on those architectures, from default live image, DVD, and boot.iso install media when written to an optical disc and when written to a USB stick with at least one of the officially supported methods"
16:51:09 * jreznik would like to be more consistent but understands it's harder to workaround...
16:51:11 <tflink> ack/nak/patch?
16:51:12 * rbergeron can't tell if this is only asus motherboards (as implied by bz title) or ... bigger?
16:51:24 <tflink> I would be that it's bigger
16:51:29 <tflink> s/be/bet/
16:51:29 <adamw> bet*
16:51:36 <adamw> yeah, from the later comments it looks more general
16:51:42 <rbergeron> okay
16:51:48 * tflink only has asus UEFI systems to test on, though
16:51:53 <rbergeron> just confirming
16:52:31 <jreznik> it doesn't matter if we accept it as blocker (and it seems like we are going to accept it as blocker)
16:52:36 <mjg59> It's pretty much only Asus
16:52:48 <mjg59> It's a specific firmware bug
16:53:01 <tflink> ah, that might change things
16:53:16 <tflink> are there enough asus UEFI systems out there to warrent blocker status?
16:53:22 <mjg59> Other people might have independently come up with the same bug, but we haven't seen any evidence of it
16:53:27 <adamw> ah
16:53:30 * tflink takes a guess that there are
16:53:35 <adamw> sigh, i hate these bureaucratic ones
16:53:42 <adamw> let's just default to nth, it moves things along
16:53:44 <tflink> yep
16:54:02 <tflink> proposed #agreed 849389 - AcceptedNTH - Violates the following F18 alpha release criterion for Asus UEFI systems: "The installer must boot (if appropriate) and run on all primary architectures, with all system firmware types that are common on those architectures, from default live image, DVD, and boot.iso install media when written to an optical disc and when written to a USB stick with at least one of the officially supported methods"
16:54:06 <adamw> if it turns into a problem somehow we can re-do it
16:54:10 <adamw> nack
16:54:18 <tflink> patch?
16:54:27 <adamw> don't cite a blocker criterion for acceptednth :)
16:54:39 <jreznik> +1 for nth, to be consistent with previous one
16:54:52 <rbergeron> +1 nth
16:55:18 <adamw> propose #agreed 849389 - AcceptedNTH - breaks install on a subset of UEFI systems, not enough to be absolutely clearly a blocker
16:55:26 <tflink> proposed #agreed 849389 - AcceptedNTH - Causes the installer to be non-bootable for Asus UEFI systems, doesn't seem to be enough systems to justify as blocker at this point in time
16:55:41 <rbergeron> ack ack, flip a coin
16:55:56 <jreznik> if it affects ASUS only, then ack for tflink's one
16:56:10 <tflink> adamw: since when do we not cite criterion for NTH? It does violate the release criteria, just not on enough systems to justify full blocker
16:56:17 <tflink> then again, I don't care enough to discuss ATM
16:56:31 <tflink> #agreed 849389 - AcceptedNTH - Causes the installer to be non-bootable for Asus UEFI systems, doesn't seem to be enough systems to justify as blocker at this point in time
16:56:38 <tflink> OK, that's all of the proposed blockers
16:56:54 <adamw> tflink: well, if you cite a criterion, best to explain why that doesn't make it a blocker.
16:56:58 <adamw> or else it reads kind of weird.
16:57:20 <adamw> yay
16:57:22 <adamw> two proposed nth?
16:57:34 <tflink> ok, I figured that "for Asus UEFI systems" was enough but either way, it's done :)
16:57:46 <tflink> yep, two of them
16:57:54 <tflink> #topic (851323) anaconda tries to poke /etc/chrony.conf at the end of install even if chrony wasn't in the installed package set
16:57:57 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=851323
16:58:00 <tflink> #info Proposed NTH, POST
16:58:23 <tflink> definitely +1 NTH on this
16:58:44 <tflink> I think it could be somewhat blockery, though since it interferes with log copying post-install
16:58:46 <jreznik> at least NTH
16:59:07 <adamw> i don't think we have any criterion for log copying
16:59:14 <adamw> +1 nth obviously
16:59:38 <tflink> proposed #agreed 851323 - AcceptedNTH - While the installed system is bootable after hitting this, it looks really bad and can interefere with other post-isntall tasks like log copying
16:59:46 <jreznik> there's patch, so should be ok with NTH
17:00:07 * rbergeron has to bail for famsco meeting/budget fun, sorry
17:00:16 <tflink> jreznik: in theory, that shouldn't affect NTH/blocker decisions
17:00:21 <tflink> rbergeron: is that in here?
17:00:38 <tflink> ack/nak/patch?
17:00:38 <rbergeron> tflink: no
17:00:43 <rbergeron> sorry :)
17:00:48 <adamw> ack
17:00:53 <tflink> ok, just making sure we weren't getting in the way
17:00:59 <jreznik> rbergeron: money, money, money!
17:01:03 <tflink> #agreed 851323 - AcceptedNTH - While the installed system is bootable after hitting this, it looks really bad and can interefere with other post-isntall tasks like log copying
17:01:17 <tflink> #topic (851653) NTPconfigError: Cannot replace the old config with the new one (Invalid cross-device link)
17:01:20 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=851653
17:01:23 <tflink> #info Proposed NTH, POST
17:01:47 <tflink> isn't this a dupe of #851323?
17:01:54 <rbergeron> tflink: agreed - we don't necessarily want to bring in something that's NTH - it could still run the risk of breaking things and causing worse problems / slips...
17:02:35 <tflink> rbergeron: we don't have to take NTH fixes if they exist
17:02:51 * rbergeron nods
17:03:06 * rbergeron thinks she worded her sentence wrong, should probably just focus on one meeting
17:03:09 <rbergeron> lol
17:03:18 <tflink> but the last one causes an installer crash, which would be best to avoid - assuming that's what you were talking about
17:03:26 <adamw> tflink: this isn't a dupe, no
17:03:31 <rbergeron> i think i was trying to say "jus because there's something doesn't mean it will be nice to have
17:03:42 <rbergeron> something = patch :)
17:04:27 <adamw> tflink: this bug claims that even if chrony is in the installed package set, anaconda still crashes, with a different error
17:04:35 <adamw> tflink: i'm not sure this one is a 100%er, though
17:04:46 <adamw> didn't others get successful installs which didn't crash at the end?
17:05:11 <tflink> not sure, I had other problems with anything outside a minimal install
17:05:22 <jreznik> adamw: I'm in touch with Martin, I can ask him for more info - how to reproduce it
17:05:47 <tflink> punt?
17:06:07 <jreznik> they are currently testing new anaconda, reporting it to rawhide (bureaucracy)... so I asked him to clone it for F18...
17:06:51 <adamw> yeah, i'd say punt on this for more details on exactly what triggers it
17:07:41 <jreznik> yep
17:07:53 <adamw> the bug's in POST, but i can't see the patch offhand
17:07:59 <tflink> proposed #agreed 851653 - It isn't clear exactly how this bug is triggered and it'd be nice to see more details before making a decision on NTH
17:08:03 <adamw> sometimes hard to match up anaconda-patches-list topics with bug #s :/
17:08:18 <tflink> ack/nak/patch?
17:08:34 <adamw> https://lists.fedorahosted.org/pipermail/anaconda-patches/2012-August/000803.html maybe
17:08:47 <adamw> suggests this might be "  Don't crash if someone gives us bad timezone"
17:09:21 <adamw> i'll ask in the bug, anyhow.
17:09:21 <adamw> ack
17:09:30 <tflink> #agreed 851653 - It isn't clear exactly how this bug is triggered and it'd be nice to see more details before making a decision on NTH
17:09:39 <tflink> OK, I think that's it for the proposed blocker/nth
17:09:51 <brunowolff> Is audio needed for alpha?
17:10:13 <tflink> I don't think so
17:10:22 <brunowolff> There is a problem with USB audio in the 3.6-rc2.git2 kernel.
17:10:28 <rwmjones> [sorry to intrude .. no FESCO meeting today right?]
17:10:46 <tflink> audio is beta
17:10:52 <adamw> rwmjones: right]
17:10:55 <rwmjones> thanks
17:10:56 <tflink> rwmjones: that is my understanding, yes
17:11:17 <adamw> okay, i think we're done with mini blocker review?
17:11:20 <jreznik> FESCo is on holydays :)
17:11:22 <tflink> yep
17:11:22 <adamw> anyone have anything we missed?
17:11:52 <brunowolff> OK. I don't think it should be NTH, though if we slip a few weeks it might get pulled in with other kernel fixes.
17:11:56 <tflink> nothing I'm aware of, no
17:12:39 <adamw> ok
17:12:42 <adamw> so very quickly...
17:12:45 <adamw> #topic open floor
17:12:53 <adamw> any other business, just in case anyone feels the meeting hasn't been long enough?
17:13:03 <jreznik> brunowolff: few weeks? it's scary... ... ... !!!!
17:13:34 <tflink> nothing big from me, might send request for feedback of reskinning of blocker tracking app if I get it done
17:13:40 <jreznik> adamw: sorry for missing the anaconda part - I agree and I'll try to be pushing more there...
17:13:53 <tflink> that'll depend on how much time is available this week, though
17:14:19 <adamw> jreznik: np, thanks
17:14:24 <tflink> reminder to weigh in on the #4 rec. to FESCo on live installs etc?
17:14:26 * adamw sets fuse for X minutes
17:14:30 <tflink> or is that going out to test@
17:14:31 <tflink> ?
17:14:38 <adamw> tflink: i'll mail the list, i actioned myself.
17:14:57 <tflink> ok, couldn't remember the outcome of that. just checking
17:15:42 <jreznik> adamw: fire it!
17:15:48 <adamw> #endmeeting