From Fedora Project Wiki
Attendees
- adamw (228)
- tflink (200)
- rbergeron (43)
- maxamillion (34)
- mjg59 (21)
- jreznik (19)
- nirik (17)
- brunowolff (16)
- zodbot (6)
- rwmjones (2)
- spoore (1)
- aspratyush (1)
Agenda
- Incomplete anaconda functionality for Fedora 18
- Fedora 18 general status check / mini blocker review
- Open floor
Incomplete anaconda functionality for Fedora 18
- See FESCo ticket
- Group discussed the issues raised in the ticket and agreed on three recommendations to be submitted to the ticket on behalf of the QA team:
- We consider it unlikely Alpha will be releasable by the time of go/no-go on Aug 29/30.
- We don't believe that reverting to oldUI is a great idea.
- 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.
Fedora 18 general status check / mini blocker review
Blocker/NTH review
- #851212 was accepted as NTH, blocker status left undetermined due to lack of data
- #851220 was accepted as a blocker, due to impact on UEFI installs
- #849982 was left undetermined as feedback still needed from design team
- #851207 was accepted as a blocker for breaking installation
- #851295 was accepted as a blocker for breaking USB installs
- #851274 was accepted as a blocker for breaking network installs
- #851500 was accepted as NTH but rejected as blocker due to breaking UEFI installation only in certain configurations
- #849389 was accepted as NTH due to affecting UEFI install on certain systems
- #851323 was accepted as NTH for obviousness of breakage and possible effect on very late installer actions
- #851653 was left undetermined due to lack of data
Open floor
N/A
Action items
- adamw to float proposed recommendation #4 on the mailing list and add it to the ticket if it gets sufficient support
IRC Log
| adamw | #startmeeting Fedora QA meeting | 15:00 |
|---|---|---|
| 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 |
| zodbot | Useful Commands: #action #agreed #halp #info #idea #link #topic. | 15:00 |
| adamw | #meetingname fedora-qa | 15:00 |
| zodbot | The meeting name has been set to 'fedora-qa' | 15:00 |
| adamw | morning, folks, who's here for some QA? | 15:01 |
| adamw | #topic roll call | 15:01 |
| * tflink is here | 15:01 | |
| * maxamillion is here | 15:01 | |
| * spoore is here | 15:02 | |
| * brunowolff is here for about 25 minutes | 15:02 | |
| * nirik is lurking in the back | 15:03 | |
| adamw | alrighty | 15:03 |
| adamw | #topic Incomplete anaconda functionality for Fedora 18 | 15:03 |
| adamw | so, in case anyone missed it, i filed a fesco ticket: https://fedorahosted.org/fesco/ticket/941 | 15:04 |
| 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:04 |
| 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 |
| 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:05 |
| 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 |
| 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:06 |
| 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:07 |
| maxamillion | ah | 15:08 |
| * nirik notes one more week slip puts us in US thanksgiving week. | 15:08 | |
| maxamillion | heh | 15:08 |
| maxamillion | this should be good | 15:08 |
| 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:08 |
| tflink | like I said, I don't think that lmc working or not is the issue ATM | 15:09 |
| tflink | we haven | 15:09 |
| 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 |
| 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:09 |
| 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 |
| maxamillion | non-installable live images would completely negate the spins project | 15:10 |
| maxamillion | I don't think that should be considered an option | 15:10 |
| 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 |
| maxamillion | ah | 15:10 |
| 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:10 |
| 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 |
| maxamillion | ok, I misunderstood the impact | 15:11 |
| tflink | not to mention the delay and extra work for the anaconda devs | 15:11 |
| 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 |
| 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:12 |
| brunowolff | How far are people willing to slip the F18 release for the new anaconda? | 15:13 |
| adamw | i think johann's right in that we need to consider the wider question of newui's overall readiness here | 15:13 |
| tflink | maxamillion: I still think that finishing the matrices this week is practical | 15:13 |
| tflink | s/is/is not/ | 15:13 |
| 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 |
| maxamillion | point* | 15:14 |
| adamw | brunowolff: are you asking us for our opinions, or wondering how others outside qa would feel about that? | 15:14 |
| brunowolff | Wondering more about outside people. | 15:14 |
| adamw | maxam_: yes, it would. it's not a free action. | 15:14 |
| maxamillion | adamw: your tab completion doesn't like me ;) | 15:15 |
| adamw | heh | 15:15 |
| maxamillion | adamw: my question to that would be "is the anaconda team even willing to do that?" | 15:15 |
| 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 |
| 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 |
| adamw | maxamillion: if fesco told them to do that, they wouldn't have a choice, i guess... | 15:15 |
| adamw | brunowolff: yeah, that's probably the most significant benefit of the oldui option. | 15:16 |
| adamw | personally, i'm not a huge fan of the oldui idea, to be honest | 15:17 |
| adamw | i do think that from a qa angle, the mandated slip option has a lot of things to like | 15:17 |
| maxamillion | I'm not a fan of the oldui option either | 15:18 |
| 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 |
| tflink | if we go the mandated slip route, would we lift freeze for a bit? | 15:18 |
| adamw | yeah, that's the key question with that option, what to do about the freeze | 15:18 |
| 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 |
| * 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 | |
| brunowolff | It would be nice for rawhide users to lift the freeze. Some updates don't get to rawhide otherwise. | 15:19 |
| tflink | adamw: any more instability than we already have? | 15:19 |
| adamw | the other option would be to pull certain big updates through the freeze - like gnome, for instance | 15:19 |
| adamw | tflink: yeah. | 15:19 |
| 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:20 |
| 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 |
| tflink | is it worth holding everyone else back because we're waiting for anaconda? | 15:21 |
| 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:21 |
| 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 |
| brunowolff | I also have some soname rebuilds waiting for a library update to clear testing. Probably some others are in this situation. | 15:22 |
| adamw | maxamillion: yeah, that option could get political. | 15:22 |
| adamw | see, this is the problem with qa, you're all too damn even-handed | 15:22 |
| maxamillion | adamw: political/flamey | 15:22 |
| maxamillion | lol | 15:23 |
| 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 |
| 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 |
| brunowolff | The final call there wouldn't be our decision. | 15:23 |
| 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 |
| 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 |
| adamw | tflink: when you say 'completed'....we aren't required to run every test for alpha, just all the alpha-level tests | 15:24 |
| maxamillion | s/hat/hats | 15:24 |
| adamw | we try to do them all, but we can sign off on a release with just the 'alpha' tests completed | 15:24 |
| tflink | true, still not convinced of the wisdom of slipping only one more week at this point | 15:25 |
| tflink | if we keep freeze, 2 weeks might be enough. if we lift freeze, I bet it would be more like 3 | 15:26 |
| adamw | yeah, that was my thinking about that line too | 15:26 |
| tflink | if we're going to lift freeze, we should do it soon | 15:26 |
| 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 |
| brunowolff | Is FESCO not meeting this week? It might be hard to get a quick response from them. | 15:27 |
| adamw | brunowolff: yeah, LPC is a problem. they're discussing the issue in the ticket rather than meeting. | 15:28 |
| tflink | adamw: I think that slipping week-by-week is a bad idea | 15:28 |
| 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 |
| brunowolff | I think we can say we don't think one week is going to be enough whichever way we go with ananaconda. | 15:28 |
| adamw | tflink: it sounds like, by elimination, you'd prefer to do a planned long slip with a freeze lift. | 15:29 |
| 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 |
| adamw | yeah. | 15:29 |
| tflink | adamw: planned longer slip - definitely. probably a freeze lift too but I don't feel as strongly about that part | 15:30 |
| brunowolff | I need to go to a work meeting. | 15:30 |
| * nirik notes this gets us into december for release... unless we somehow shorten something else. | 15:30 | |
| tflink | I suppose we could just skip alpha altogether but I'm not sure that's a great idea | 15:30 |
| * 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 | |
| * adamw trying to synthesize a list of recommendations for people to vote on | 15:31 | |
| tflink | adamw: split them up into separate items? revert to pre-newui, slip more than one week, lift freeze | 15:32 |
| tflink | ? | 15:32 |
| adamw | tflink: yeah, that's what i'm doing | 15:32 |
| adamw | so far i've got this | 15:33 |
| adamw | 1. We consider it unlikely Alpha will be releasable by the time of go/no-go on Aug 29/30. | 15:33 |
| adamw | 2. We don't believe that reverting to oldUI is a great idea. | 15:33 |
| 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:33 |
| 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 |
| adamw | or if we should water it down a bit | 15:34 |
| adamw | thoughts? | 15:34 |
| tflink | how many of the anaconda devs are at LPC? | 15:35 |
| adamw | my impression was basically everyone but jesse | 15:35 |
| adamw | jesse said something about being left holding the can | 15:35 |
| tflink | then I'd be more for the 3 or more week slip | 15:36 |
| tflink | if they're mostly at LPC, I don't think this week counts | 15:36 |
| maxamillion | +1 | 15:37 |
| tflink | which could possibly give releng enough time to get lmc working in koji | 15:37 |
| * adamw is clarifying in #anaconda at present | 15:37 | |
| 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:38 |
| adamw | okay, so lpc is not as much of a problem as we thought | 15:39 |
| adamw | dcantrell, pjones and bcl are the ones out | 15:39 |
| 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 |
| * 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:41 | |
| nirik | so best case: 1 week slip probibly? | 15:42 |
| adamw | it would be nice for fesco to make a decision by thursday, tbh. | 15:42 |
| 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 |
| adamw | if you believe that, i've got this bridge for sale... | 15:42 |
| * nirik nods | 15:43 | |
| * tflink thinks that one more slip is a bit on the optimistic side | 15:43 | |
| tflink | but then again, I'm a bit of a cynic | 15:43 |
| adamw | =) | 15:43 |
| maxamillion | s/cynic/realist/ | 15:44 |
| 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 |
| maxamillion | granted, they are basically synonyms these days | 15:44 |
| adamw | does anyone want to take a shot at better recommendations than my three? or shall we just go with those? | 15:44 |
| maxamillion | I'm good with those | 15:44 |
| maxamillion | brb ... in dire need of more coffee | 15:45 |
| tflink | I'm in favor of adding your #4 | 15:45 |
| tflink | I doubt that will be the option chosen, but it makes #3 seem less drastic | 15:45 |
| adamw | hah. you're a politician too. | 15:45 |
| tflink | in my experience, choosing release dates has more to do with politics than anything, anyways | 15:46 |
| adamw | ok, let's make it all official, two parts seems like it'd be best | 15:46 |
| adamw | first: propose #agreed we submit the three recommendations drafted above to the fesco ticket | 15:46 |
| adamw | vote! | 15:46 |
| tflink | what about the 4th? | 15:46 |
| adamw | that's the second proposal | 15:47 |
| adamw | i figured this one will go through easy, it's just a prelim | 15:47 |
| adamw | then we vote on taking the 4th =) | 15:47 |
| tflink | ok, just checking before voting | 15:47 |
| tflink | +1 | 15:47 |
| adamw | who else is alive | 15:48 |
| tflink | brno folks are away until wed | 15:49 |
| tflink | I think we lost everyone else, too | 15:49 |
| tflink | :( | 15:49 |
| adamw | nirik was still soldiering on until two minutes ago | 15:49 |
| tflink | I think that maxamillion will be back in a minute or so | 15:49 |
| adamw | but i guess he finally couldn't take the qa jungle heat any mor | 15:49 |
| adamw | e | 15:49 |
| tflink | he said something about coffee | 15:49 |
| nirik | ha. | 15:49 |
| adamw | speaking of... | 15:49 |
| nirik | I think your 1-3 are reasonable... | 15:50 |
| adamw | ok, so that's a +1 | 15:50 |
| tflink | one of the other interesting side effects of a long slip is the time between F18 and F19 | 15:50 |
| * adamw waits for maxam | 15:50 | |
| nirik | tflink: yep. | 15:50 |
| adamw | yeah, i don't think we have to consider all those implications though, that's a fesco/board job i guess. | 15:50 |
| nirik | the next cycle will need to be shorter, or move our 'traditional' dates. | 15:50 |
| maxamillion | back | 15:51 |
| adamw | got a vote on proposal #1? | 15:51 |
| maxamillion | +1 | 15:52 |
| adamw | ok | 15:52 |
| adamw | #agreed we submit the three recommendations drafted above to the fesco ticket | 15:52 |
| tflink | adamw: you might want to #info those so that they show up in minutes | 15:52 |
| adamw | propose #agreed we submit the proposed fourth recommendation, moderately in favour of a longer slip with a freeze lift | 15:52 |
| adamw | tflink: oh yeah. | 15:52 |
| tflink | probably before the agreed | 15:52 |
| adamw | #undo | 15:52 |
| zodbot | Removing item from minutes: <MeetBot.items.Agreed object at 0x1a36cf90> | 15:52 |
| adamw | #info for the record, the recommendations are: | 15:53 |
| adamw | #info 1. We consider it unlikely Alpha will be releasable by the time of go/no-go on Aug 29/30. | 15:53 |
| adamw | #info 2. We don't believe that reverting to oldUI is a great idea. | 15:53 |
| 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 |
| adamw | #agreed we submit the three recommendations drafted above to the fesco ticket | 15:53 |
| * rbergeron also notes we are running into holidays, etc., particularly thxgiving in the us ... sorry to just drop in | 15:54 | |
| 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 |
| tflink | +1 | 15:54 |
| adamw | rbergeron: i mostly think that's for fesco to consider rather than us | 15:54 |
| maxamillion | +1 | 15:54 |
| * rbergeron nods | 15:54 | |
| nirik | rbergeron: one week slip gets us in thanksgiving week. More than that gets into december | 15:54 |
| rbergeron | yep | 15:54 |
| adamw | we're not deciding the issue, just providing an official qa recommendations | 15:54 |
| adamw | recommendation* | 15:55 |
| maxamillion | Fedora: X-Mas Edition ... >.> | 15:55 |
| tflink | assuming that we don't slip for beta or final, either | 15:55 |
| maxamillion | errr | 15:55 |
| maxamillion | Fedora: Winter Edititon | 15:55 |
| rbergeron | tflink: hahahahahaha | 15:55 |
| rbergeron | :D | 15:55 |
| adamw | Winter Solstice Edition | 15:55 |
| maxamillion | :) | 15:55 |
| * tflink has visions of a spherical cow w/ a santa hat in his head | 15:55 | |
| tflink | s/his/its/ | 15:55 |
| rbergeron | and a gift containing a snake | 15:55 |
| maxamillion | that would be *awesome* | 15:55 |
| adamw | nirik: what's your feeling? | 15:55 |
| nirik | I'm not sure I favor that personally. ;) | 15:56 |
| adamw | the recommendation, the santa hat, the snake, or all three? :) | 15:56 |
| tflink | I'm not sure I like the idea, either. I just think it's the best option at this point | 15:56 |
| nirik | if we could do 1 or 2 weeks slip, IMHO I would find that better... | 15:56 |
| nirik | but not sure how likely that will be | 15:56 |
| maxamillion | suppose that depends on how likely you are to accept that miracles are a reality | 15:57 |
| adamw | so that feels like 2 +1s and a -0.5 | 15:57 |
| adamw | probably not strong enough to pass on such a strong point as representing the team | 15:58 |
| tflink | we're missing a lot of people, too | 15:58 |
| adamw | of course, the +1s could state their personal opinions in the ticket. so maybe we should just go with that. | 15:58 |
| 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 |
| adamw | ? | 15:59 |
| tflink | or wait until we have more people before suggesting #4? | 15:59 |
| adamw | i don't think any more people are going to show up to this meeting | 16:00 |
| tflink | that'll take me a minute to get ready. I'm not sure why it keeps catching me by surprise | 16:00 |
| tflink | I didn't mean at the meeting | 16:00 |
| rbergeron | does the anaconda team have a fairly firmed up list of "what's left" at this point? | 16:00 |
| 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 |
| adamw | tflink: i can float it on the list for sure, | 16:00 |
| 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:00 |
| adamw | the next big pain point is the upgrade code, i suspect. | 16:01 |
| adamw | that will likely be our big ass-kicker at beta point. | 16:01 |
| 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 |
| 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 |
| * rbergeron shuts up now :D | 16:02 | |
| 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 |
| 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 |
| tflink | include upgrade code, too | 16:03 |
| * tflink wasn't thinking about that yet | 16:03 | |
| 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: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 |
| adamw | this whole 'writing the code as we validate it' thing is not working out too well. =) | 16:04 |
| rbergeron | i would think anyway | 16:04 |
| adamw | rbergeron: roger | 16:04 |
| * rbergeron = not in fesco obviously | 16:04 | |
| rbergeron | :D | 16:04 |
| adamw | but your very word is law | 16:04 |
| adamw | LAW | 16:04 |
| rbergeron | lame and womanly? large and waffles? | 16:05 |
| * rbergeron hangs out for blockers | 16:05 | |
| tflink | your very word is waffles? | 16:05 |
| tflink | not sure what that means :) | 16:05 |
| 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:05 |
| adamw | or is that too much fiddling? | 16:06 |
| adamw | probably not necessary.... | 16:06 |
| adamw | okay, ignore me. let's blocker review. | 16:06 |
| rbergeron | i think nobody will disagree :D | 16:06 |
| tflink | I think it would be nice to see | 16:06 |
| adamw | #topic Fedora 18 Alpha mini blocker review | 16:06 |
| adamw | tflink: i'll just throw it in as 'deep background', easier that way. | 16:06 |
| tflink | adamw: can you #chair me? | 16:07 |
| adamw | #chair tflink | 16:07 |
| zodbot | Current chairs: adamw tflink | 16:07 |
| adamw | #chair rbergeron | 16:07 |
| zodbot | Current chairs: adamw rbergeron tflink | 16:07 |
| * tflink is planning to just do the proposed blockers and NTH today | 16:07 | |
| tflink | #info 8 Proposed Blockers | 16:07 |
| tflink | #info 2 Proposed NTH | 16:08 |
| adamw | yeah, we're over time already | 16:08 |
| tflink | starting with the proposed blockers ... | 16:08 |
| adamw | we'll probably have to move into -1, unless we're quick. | 16:08 |
| tflink | fesco isn't meeting today | 16:08 |
| tflink | #topic (851212) error: cannot invoke setopt() - perform() is currently running | 16:08 |
| tflink | #link https://bugzilla.redhat.com/show_bug.cgi?id=851212 | 16:08 |
| tflink | #info Proposed Blockers, POST | 16:08 |
| adamw | oh right, it's fesco that always kicks us out. | 16:09 |
| tflink | I'm not sure about blocker on this but +1 nth | 16:10 |
| adamw | well, a crash at the language selection screen is bad news | 16:10 |
| tflink | true | 16:10 |
| tflink | but is an intermittant crash a blocker for alpha? | 16:10 |
| adamw | yeah, probably needs more data | 16:11 |
| adamw | if other people start hitting it then i'd be +1 | 16:11 |
| adamw | +1 nth for sure | 16:11 |
| adamw | are you -1 blocker or punt? | 16:11 |
| rbergeron | nth/more data | 16:11 |
| tflink | sounds like #851207 might be masking more occurances, though | 16:11 |
| tflink | punt | 16:11 |
| adamw | roger | 16:12 |
| adamw | hi andre | 16:12 |
| adamw | we're just cranking up blocker review | 16:12 |
| adamw | i'm fine with accept as NTH, punt on blocker | 16:12 |
| 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 |
| rbergeron | +1 | 16:13 |
| tflink | ack/nak/patch? | 16:13 |
| adamw | ack | 16:13 |
| aspratyush | ack | 16:14 |
| 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 |
| tflink | #topic (851220) EFI syslinux contains wrong path to kernel pair | 16:14 |
| tflink | #link https://bugzilla.redhat.com/show_bug.cgi?id=851220 | 16:14 |
| tflink | #info Proposed Blockers, ASSIGNED | 16:14 |
| rbergeron | multibug :D | 16:15 |
| tflink | +1 blocker | 16:16 |
| mjg59 | Entertainingly mistitled | 16:16 |
| 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 |
| adamw | ack | 16:17 |
| tflink | I bet that's too long, again | 16:17 |
| adamw | nope, that one made it. | 16:17 |
| nirik | ack | 16:17 |
| tflink | cool, I should really figure out the max chars that can be in one line | 16:17 |
| rbergeron | 510 | 16:18 |
| rbergeron | can vary by server though also :D | 16:18 |
| rbergeron | ack | 16:18 |
| 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 |
| tflink | rbergeron: sounds like you've hit this in the past :) | 16:18 |
| tflink | the # of chars thing, I mean | 16:19 |
| rbergeron | tflink: yes, but google is also awesome | 16:19 |
| tflink | #topic (849982) The default Fedora 18 artwork refers to the previous release in F18 Alpha TC3 | 16:19 |
| tflink | #link https://bugzilla.redhat.com/show_bug.cgi?id=849982 | 16:19 |
| tflink | #info Proposed Blockers, NEW | 16:19 |
| tflink | rbergeron: you mean that I should have googled for the answer to my question? That sounds like too much work :) | 16:19 |
| adamw | oh, right, we punted this to talk to design team. then, er, did anyone talk to design team? | 16:19 |
| adamw | i didn't. oops. | 16:19 |
| tflink | yeah, I was wondering about that too | 16:20 |
| tflink | punt until wed? | 16:20 |
| tflink | AFAIK, we still don't have an installable gnome DE | 16:20 |
| adamw | re-punt, if no-one got new info. | 16:21 |
| 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:21 |
| 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 |
| tflink | #link https://bugzilla.redhat.com/show_bug.cgi?id=851207 | 16:22 |
| tflink | #info Proposed Blockers, NEW | 16:22 |
| tflink | this sounds like blocker for me | 16:23 |
| adamw | how does it differ from 851212? | 16:23 |
| adamw | just cos he saw this one twice? :) | 16:23 |
| tflink | sounds like a lock versus wrong method issue | 16:23 |
| tflink | to me, at least | 16:23 |
| tflink | wrong method/improper call | 16:24 |
| adamw | oh, man, you're going to get all technical on me?! | 16:24 |
| adamw | ok, seriously, fair point | 16:24 |
| tflink | "The installer must be able to complete package installation with the default package set for each supported installation method"? | 16:25 |
| adamw | ah, more ipv6 stuff, looks like | 16:25 |
| adamw | from the tb anyhow | 16:25 |
| rbergeron | adamw: maybe he would have seen it a third time if he hadn't hit 851212? | 16:25 |
| adamw | pick a criterion. that one works. | 16:25 |
| adamw | rbergeron: yeah, it kinda looks that way. | 16:25 |
| * rbergeron suspects kamil might just be underscoring the fact that workaround isn't an option | 16:25 | |
| 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:25 |
| adamw | ack | 16:26 |
| rbergeron | ack | 16:26 |
| 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 |
| tflink | #topic (851295) splitsep doesn't correctly handle variables with escaped spaces | 16:27 |
| tflink | #link https://bugzilla.redhat.com/show_bug.cgi?id=851295 | 16:27 |
| tflink | #info Proposed Blockers, MODIFIED | 16:27 |
| tflink | pretty clear blocker | 16:28 |
| 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 |
| 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:28 |
| tflink | I think it breaks USB media mostly | 16:29 |
| adamw | if it does in fact break usb i'm happy with that criterion | 16:29 |
| tflink | IIRC, litd specifies stage2 which doesn | 16:29 |
| tflink | t work when the path gets mangled | 16:29 |
| adamw | i thought at present litd wasn't appending any parameters | 16:30 |
| adamw | but imbw there | 16:30 |
| tflink | makes 2 of us, I could easily be wrong on my understanding | 16:30 |
| adamw | meh, we're way behind anyhow | 16:30 |
| adamw | let's just take it on that basis and we can modify later if needs be. | 16:30 |
| tflink | but I suppose that it would break network isntalls if it doesn't break USB | 16:30 |
| adamw | ack then | 16:31 |
| adamw | yeah, it's really just a case of which criterion we go for. | 16:31 |
| adamw | although, that might make it beta. eh. | 16: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 |
| tflink | I thought that we needed at least 1 of ftp/http at alpha | 16:31 |
| tflink | nvm, different wording | 16:32 |
| adamw | well it'd only be a problem if you specify a repo on the kernel command line, aiui. | 16:32 |
| adamw | not if you do it interactively. | 16:32 |
| tflink | yeah, it's more of a PXE issue | 16:32 |
| adamw | oh well, move on! | 16:32 |
| tflink | yep | 16:32 |
| tflink | #topic (851274) Traceback during install - mount: /dev/sr0 is already mounted or /run/install/repo busy | 16:32 |
| tflink | #link https://bugzilla.redhat.com/show_bug.cgi?id=851274 | 16:32 |
| tflink | #info Proposed Blockers, ASSIGNED | 16:32 |
| adamw | we never acked this yet? | 16:33 |
| adamw | well, +1, obviously. | 16:33 |
| tflink | yep, same here | 16:33 |
| tflink | "The installer must be able to complete package installation with the default package set for each supported installation method"? | 16:33 |
| * jreznik is reading backlog | 16:33 | |
| 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 |
| tflink | ack/nak/patch? | 16:34 |
| adamw | ack | 16:34 |
| 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:35 |
| tflink | #topic (851500) UEFI boot: failure reading sector 0x40 from `cd0'. | 16:36 |
| tflink | #link https://bugzilla.redhat.com/show_bug.cgi?id=851500 | 16:36 |
| tflink | #info Proposed Blockers, NEW | 16:36 |
| tflink | hrm, not sure there's enough info here yet | 16:37 |
| tflink | the later comments make it sound like a bit of an obscure problem | 16:37 |
| adamw | yeah, i'm -0.5 on this | 16:38 |
| tflink | I guess the question comes down to punt or reject? | 16:38 |
| adamw | i think reject and ask him to file the kernel panic | 16:38 |
| mjg59 | I've got a patch for 851500 | 16:38 |
| mjg59 | Ah, it's even uploaded already | 16:39 |
| adamw | mjg59: are the 'failure reading' error message and the kernel panic connected? | 16:39 |
| mjg59 | Yes | 16:39 |
| adamw | that's the key question here | 16:39 |
| mjg59 | The kernel panics because there's no initramfs | 16:39 |
| adamw | ah, that makes it much more +1. | 16:39 |
| adamw | definitely +1 nth | 16:39 |
| mjg59 | pjones uploaded the patch on August 15th | 16:40 |
| * rbergeron is nth here as well | 16:40 | |
| adamw | mjg59: how common is the issue likely to be? is it specific to a model, a firmware or what? | 16:40 |
| mjg59 | So should just need a newer grub2-efi tagged in | 16:40 |
| mjg59 | adamw: It's a timing issue. Depends on how good your CD drive is. | 16:40 |
| mjg59 | Short version: Intel can't write code for shit | 16:40 |
| mjg59 | Their ahci driver times out when doing large reads from slow media. Like the 20MB initramfs off a CD. | 16:41 |
| 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 |
| mjg59 | We were hitting it on about 20% of tested systems | 16:41 |
| adamw | mjg59: i don't see this issue referenced in the grub2 changelog anywhere | 16:41 |
| mjg59 | c1a25d07e636b5164c7ae225fbd395baed464af5 | 16:42 |
| adamw | is the patch definitely in the f18 grub2 tree? | 16:42 |
| mjg59 | "Work around AHCI firmware bug in efidisk driver" | 16:42 |
| jreznik | 20% seems quite a lot for me | 16:42 |
| mjg59 | adamw: Seems to be here | 16:42 |
| adamw | ah, k | 16:42 |
| tflink | is 20% enough for blocker? | 16:43 |
| * tflink is on the fence | 16:43 | |
| adamw | 20% of uefi installs | 16:43 |
| tflink | definitely +1 NTH, not so sure about blocker yet | 16:43 |
| mjg59 | Like I said, the bug is fixed, just needs to be tagged | 16:43 |
| adamw | right, so it's pretty academic | 16:43 |
| jreznik | how many people do we expect to use uefi? | 16:43 |
| adamw | jreznik: quite small atm. | 16:43 |
| tflink | in a fantasy world or in reality? | 16:43 |
| mjg59 | Enough that you've already flagged some UEFI-specific bugs as blockers | 16:44 |
| adamw | but getting ever bigger. | 16:44 |
| tflink | I'm going to go with +1 nth, -1 blocker | 16:44 |
| tflink | there are acceptable workarounds (USB) and it only hits 20% of systems | 16:45 |
| adamw | yeah, agreed | 16:45 |
| adamw | mjg59: don't worry, this is just bureaucracy, either way the fix goes in. | 16:45 |
| adamw | in fact it'd be going in anyway as we're already pulling that update for another nth issue. | 16:45 |
| adamw | so just #agreed it and let's move on =) | 16:45 |
| * rbergeron puts up +1 nth in her window with pretty red tape | 16:45 | |
| jreznik | okm +1 | 16:45 |
| * adamw just wanted to check the 'fix' didn't go into tc3 already and hence it wasn't working | 16:46 | |
| jreznik | rbergeron: blue one here! | 16:46 |
| adamw | i kinda thought we had -5 in tc3. but i was wrong, it's slated for tc4. | 16:46 |
| 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 |
| rbergeron | jreznik: mine was for the red tape of bureaucracy ;) | 16:46 |
| adamw | ack | 16:46 |
| adamw | well, usb would be an acceptable workaround if *it* worked =) | 16:46 |
| tflink | details ... | 16:47 |
| tflink | other ack/nak/patch? | 16:47 |
| adamw | i think we have implied acks... | 16:48 |
| mjg59 | adamw: USB should work for dded media, just not litd | 16:48 |
| 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 |
| tflink | #topic (849389) uefi boot fails on Asus motherboards | 16:48 |
| tflink | #link https://bugzilla.redhat.com/show_bug.cgi?id=849389 | 16:48 |
| tflink | #info Proposed Blockers, ON_QA | 16:48 |
| mjg59 | This should be fixed in the kernel, again just needs tagging | 16:49 |
| adamw | seems to affect quite a lot of systems | 16:50 |
| tflink | sounds like a blocker to me | 16:50 |
| adamw | and less workaroundable than the last one | 16:50 |
| adamw | +1 blocker for me too | 16:50 |
| 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 |
| * jreznik would like to be more consistent but understands it's harder to workaround... | 16:51 | |
| tflink | ack/nak/patch? | 16:51 |
| * rbergeron can't tell if this is only asus motherboards (as implied by bz title) or ... bigger? | 16:51 | |
| tflink | I would be that it's bigger | 16:51 |
| tflink | s/be/bet/ | 16:51 |
| adamw | bet* | 16:51 |
| adamw | yeah, from the later comments it looks more general | 16:51 |
| rbergeron | okay | 16:51 |
| * tflink only has asus UEFI systems to test on, though | 16:51 | |
| rbergeron | just confirming | 16:51 |
| 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 |
| mjg59 | It's pretty much only Asus | 16:52 |
| mjg59 | It's a specific firmware bug | 16:52 |
| tflink | ah, that might change things | 16:53 |
| tflink | are there enough asus UEFI systems out there to warrent blocker status? | 16:53 |
| mjg59 | Other people might have independently come up with the same bug, but we haven't seen any evidence of it | 16:53 |
| adamw | ah | 16:53 |
| * tflink takes a guess that there are | 16:53 | |
| adamw | sigh, i hate these bureaucratic ones | 16:53 |
| adamw | let's just default to nth, it moves things along | 16:53 |
| tflink | yep | 16:53 |
| 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 |
| adamw | if it turns into a problem somehow we can re-do it | 16:54 |
| adamw | nack | 16:54 |
| tflink | patch? | 16:54 |
| adamw | don't cite a blocker criterion for acceptednth :) | 16:54 |
| jreznik | +1 for nth, to be consistent with previous one | 16:54 |
| rbergeron | +1 nth | 16:54 |
| adamw | propose #agreed 849389 - AcceptedNTH - breaks install on a subset of UEFI systems, not enough to be absolutely clearly a blocker | 16:55 |
| 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 |
| rbergeron | ack ack, flip a coin | 16:55 |
| jreznik | if it affects ASUS only, then ack for tflink's one | 16:55 |
| 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 |
| tflink | then again, I don't care enough to discuss ATM | 16:56 |
| 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 |
| tflink | OK, that's all of the proposed blockers | 16:56 |
| adamw | tflink: well, if you cite a criterion, best to explain why that doesn't make it a blocker. | 16:56 |
| adamw | or else it reads kind of weird. | 16:56 |
| adamw | yay | 16:57 |
| adamw | two proposed nth? | 16:57 |
| tflink | ok, I figured that "for Asus UEFI systems" was enough but either way, it's done :) | 16:57 |
| tflink | yep, two of them | 16:57 |
| 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 |
| tflink | #link https://bugzilla.redhat.com/show_bug.cgi?id=851323 | 16:57 |
| tflink | #info Proposed NTH, POST | 16:58 |
| tflink | definitely +1 NTH on this | 16:58 |
| tflink | I think it could be somewhat blockery, though since it interferes with log copying post-install | 16:58 |
| jreznik | at least NTH | 16:58 |
| adamw | i don't think we have any criterion for log copying | 16:59 |
| adamw | +1 nth obviously | 16:59 |
| 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 |
| jreznik | there's patch, so should be ok with NTH | 16:59 |
| * rbergeron has to bail for famsco meeting/budget fun, sorry | 17:00 | |
| tflink | jreznik: in theory, that shouldn't affect NTH/blocker decisions | 17:00 |
| tflink | rbergeron: is that in here? | 17:00 |
| tflink | ack/nak/patch? | 17:00 |
| rbergeron | tflink: no | 17:00 |
| rbergeron | sorry :) | 17:00 |
| adamw | ack | 17:00 |
| tflink | ok, just making sure we weren't getting in the way | 17:00 |
| jreznik | rbergeron: money, money, money! | 17:00 |
| 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 |
| tflink | #topic (851653) NTPconfigError: Cannot replace the old config with the new one (Invalid cross-device link) | 17:01 |
| tflink | #link https://bugzilla.redhat.com/show_bug.cgi?id=851653 | 17:01 |
| tflink | #info Proposed NTH, POST | 17:01 |
| tflink | isn't this a dupe of #851323? | 17:01 |
| 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:01 |
| tflink | rbergeron: we don't have to take NTH fixes if they exist | 17:02 |
| * rbergeron nods | 17:02 | |
| * rbergeron thinks she worded her sentence wrong, should probably just focus on one meeting | 17:03 | |
| rbergeron | lol | 17:03 |
| 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 |
| adamw | tflink: this isn't a dupe, no | 17:03 |
| rbergeron | i think i was trying to say "jus because there's something doesn't mean it will be nice to have | 17:03 |
| rbergeron | something = patch :) | 17:03 |
| adamw | tflink: this bug claims that even if chrony is in the installed package set, anaconda still crashes, with a different error | 17:04 |
| adamw | tflink: i'm not sure this one is a 100%er, though | 17:04 |
| adamw | didn't others get successful installs which didn't crash at the end? | 17:04 |
| tflink | not sure, I had other problems with anything outside a minimal install | 17:05 |
| jreznik | adamw: I'm in touch with Martin, I can ask him for more info - how to reproduce it | 17:05 |
| tflink | punt? | 17:05 |
| jreznik | they are currently testing new anaconda, reporting it to rawhide (bureaucracy)... so I asked him to clone it for F18... | 17:06 |
| adamw | yeah, i'd say punt on this for more details on exactly what triggers it | 17:06 |
| jreznik | yep | 17:07 |
| adamw | the bug's in POST, but i can't see the patch offhand | 17:07 |
| 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:07 |
| adamw | sometimes hard to match up anaconda-patches-list topics with bug #s :/ | 17:08 |
| tflink | ack/nak/patch? | 17:08 |
| adamw | https://lists.fedorahosted.org/pipermail/anaconda-patches/2012-August/000803.html maybe | 17:08 |
| adamw | suggests this might be " Don't crash if someone gives us bad timezone" | 17:08 |
| adamw | i'll ask in the bug, anyhow. | 17:09 |
| adamw | ack | 17:09 |
| 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 |
| tflink | OK, I think that's it for the proposed blocker/nth | 17:09 |
| brunowolff | Is audio needed for alpha? | 17:09 |
| tflink | I don't think so | 17:10 |
| brunowolff | There is a problem with USB audio in the 3.6-rc2.git2 kernel. | 17:10 |
| rwmjones | [sorry to intrude .. no FESCO meeting today right?] | 17:10 |
| tflink | audio is beta | 17:10 |
| adamw | rwmjones: right] | 17:10 |
| rwmjones | thanks | 17:10 |
| tflink | rwmjones: that is my understanding, yes | 17:10 |
| adamw | okay, i think we're done with mini blocker review? | 17:11 |
| jreznik | FESCo is on holydays :) | 17:11 |
| tflink | yep | 17:11 |
| adamw | anyone have anything we missed? | 17:11 |
| 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 |
| tflink | nothing I'm aware of, no | 17:11 |
| adamw | ok | 17:12 |
| adamw | so very quickly... | 17:12 |
| adamw | #topic open floor | 17:12 |
| adamw | any other business, just in case anyone feels the meeting hasn't been long enough? | 17:12 |
| jreznik | brunowolff: few weeks? it's scary... ... ... !!!! | 17:13 |
| tflink | nothing big from me, might send request for feedback of reskinning of blocker tracking app if I get it done | 17:13 |
| jreznik | adamw: sorry for missing the anaconda part - I agree and I'll try to be pushing more there... | 17:13 |
| tflink | that'll depend on how much time is available this week, though | 17:13 |
| adamw | jreznik: np, thanks | 17:14 |
| tflink | reminder to weigh in on the #4 rec. to FESCo on live installs etc? | 17:14 |
| * adamw sets fuse for X minutes | 17:14 | |
| tflink | or is that going out to test@ | 17:14 |
| tflink | ? | 17:14 |
| adamw | tflink: i'll mail the list, i actioned myself. | 17:14 |
| tflink | ok, couldn't remember the outcome of that. just checking | 17:14 |
| jreznik | adamw: fire it! | 17:15 |
| adamw | #endmeeting | 17:15 |
Generated by irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!