18:00:18 <t8m> #startmeeting FESCO (2012-11-07)
18:00:18 <zodbot> Meeting started Wed Nov  7 18:00:18 2012 UTC.  The chair is t8m. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:18 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:19 <t8m> #meetingname fesco
18:00:19 <zodbot> The meeting name has been set to 'fesco'
18:00:27 <t8m> #chair notting nirik mjg59 mmaslano t8m pjones mitr limburgher jwb
18:00:27 <zodbot> Current chairs: jwb limburgher mitr mjg59 mmaslano nirik notting pjones t8m
18:00:27 <t8m> #topic init process
18:00:32 <t8m> Hi all
18:00:33 <nirik> morning all.
18:00:35 <mitr> Hello
18:00:42 <jwb> hi
18:00:47 <mmaslano> hi
18:00:54 <pjones> hello.
18:01:01 * notting is here
18:01:39 <limburgher> hi
18:01:53 <t8m> mjg59, around?
18:02:01 <mjg59> Hi
18:02:29 <t8m> Nice, every FESCo member is on-line
18:02:37 <t8m> So let's start
18:02:44 <t8m> #topic #960 F18 schedule + the holidays
18:02:49 <t8m> .fesco 960
18:02:50 <zodbot> t8m: #960 (F18 schedule + the holidays) – FESCo - https://fedorahosted.org/fesco/ticket/960
18:03:08 <t8m> we should discuss it together with the proposal in 968
18:03:12 <notting> do we have a guesstimate whether we're go or no-go this week?
18:03:12 <t8m> .fesco 968
18:03:14 <zodbot> t8m: #968 (Move F18 release to no more than March 2013) – FESCo - https://fedorahosted.org/fesco/ticket/968
18:03:42 <jreznik> notting: no-go, 99%
18:03:56 <jwb> jreznik, why
18:04:18 <jreznik> jwb: we do not have rc yet, and bunch of blocker bugs
18:04:44 <jreznik> update one from today's blocker bug meeting http://qa.fedoraproject.org/blockerbugs/milestone/18/beta/buglist
18:05:13 <adamw> fedup is still not really baked yet
18:05:15 <tflink> yeah, I'd honestly be surprised if we were in go status by thursday
18:05:49 <jreznik> if anyone can help looking on the bugs, would be great... some folk are at linuxcon, so...
18:05:55 <t8m> My opinion is we should forget the release this year and try to create realistic schedule that would allow to give the anaconda polish it needs
18:05:58 <tflink> fedup still has some major issues and I haven't seen a clear answer on how we're going to handle the initramfs build and hosting
18:06:13 <mitr> tflink: "hosting"?
18:06:33 * nirik thinks if we slip thursday, we slip. Thats one more week, so release would be the 18th...
18:06:34 <tflink> mitr: the current process involves a side repo with a kernel and initramfs built for the upgrade
18:06:36 <notting> tflink: it would be another image that lorax spitsout, no?
18:06:37 <mjg59> I'd just like to note at this point that we have more people setting flags on fedup bugs than we have doing any development work on fedup
18:06:54 <pjones> mjg59: yeah, that's... a problem.
18:07:08 <mjg59> And that seriously people this is code. You know how to do code.
18:07:10 <mjg59> Work on the code.
18:07:10 <tflink> notting: in theory, yes but I don't know what the plan is. only what the current process is
18:07:14 <pjones> the degree of overhead generation is stunning.
18:08:02 <mjg59> Anyway. -1 to 968.
18:08:14 <nirik> anyhow, my take: defer 960 for now, -1 to 968
18:08:15 <jreznik> yep, the development is blocked on one guy..
18:08:31 <jwb> two
18:08:43 <notting> mjg59: pjones: is there a task list? (not that ii have *any* time to add to it now, but for reference...)
18:08:53 <mjg59> notting: There's the fixmes in the code
18:09:00 <mjg59> notting: ISO support is missing, as is parsing of releases.txt
18:09:08 <mjg59> notting: Other than that, the commandline tool works
18:09:14 <t8m> The question is whether some realistic date (not as far as March) would not be better from the marketing point of view rather than continuously slipping.
18:09:33 <tflink> mjg59: define works. I would argue that the process as a whole is not working right now
18:09:37 <jreznik> t8m: for more realistic schedule - we definitely need a real deadline, the question is what's acceptable - not to affect f19 etc., not to affect our standards..
18:09:39 <limburgher> How about mid-late January?
18:09:41 <pjones> t8m: and also from other points of view.
18:09:49 <notting> mjg59: and then the followup would be where the coordination point is other than 'grab wwoods on irc'
18:09:56 <mitr> jreznik: deadline = willingness to release even if functionality is limited
18:10:02 <mjg59> tflink: I don't understand
18:10:03 <jwb> jreznik, i think the point of not effecting f19 is well past
18:10:09 <jreznik> mitr: yep, that's what I'm talking about
18:10:11 <mitr> t8m: I wouldn't expect marketing to need that much advance notice
18:10:17 <mjg59> notting: Well right right now it appears to be grab wwoods on irc
18:10:20 <tflink> mjg59: https://bugzilla.redhat.com/show_bug.cgi?id=873459
18:10:31 <tflink> the f17 cli works, yes
18:10:37 <mjg59> tflink: So sure yes there are bugs
18:10:48 * rbergeron pops in and represents marketing and stuff
18:10:49 <jwb> mitr, i think he meant "we look incompetent to keep slipping when we say we're going to ship".  PR, not really marketing
18:10:49 <t8m> mitr, I mean the "marketing message" the continous slip gives
18:10:56 <mjg59> tflink: But that's not a work that needs doing list, that's a bug list
18:11:04 <mjg59> We can't give a deadline
18:11:13 <mjg59> The work will be done when it's done
18:11:20 <mjg59> If people would actually do some of the work, the work would be done sooner
18:11:32 <t8m> jwb, yep PR is better term
18:11:41 <adamw> jwb: fwiw, the response so far has been amazingly positive.
18:11:41 <notting> we could rename fedup to DukeNukemForever, but that's already taken in the distro
18:11:44 <tflink> mjg59: I know that's a bug list. I was just saying that the fedup process as a whole isn't working right now
18:11:52 <adamw> every time someone publishes a story on fedora slipping, lots of people comment that it's a good thing.
18:11:56 <tflink> but I think we're saying pretty much the same thing with different phrasing
18:12:00 <jwb> adamw, what alternate reality are you living in and how to i get there?
18:12:17 <mjg59> So right now the PR message I see is that people are more interested in talking about process than actually fixing the product
18:12:28 <pjones> adamw: that indicates that they think it's better than shipping junk.  not that we haven't royally screwed this whole thing up.
18:12:29 <t8m> adamw, I'm curious why can that be possible
18:12:31 <rbergeron> it means that people recognize that we're not cutting corners and shipping a pile of crap.
18:12:43 <pjones> rbergeron: exactly.
18:12:47 <limburgher> Yes.
18:12:57 <jreznik> rbergeron: but this can't work forever this way...
18:13:01 * nirik agrees with adamw on the press side... I have seen the same thing.
18:13:11 <notting> rbergeron: pjones: yes. that being said, it's probably worth discussing whether week-to-week is the best way to keep doing it
18:13:24 <rbergeron> that we do have some level of ship-worthyness and that we're not beholden to a ship-or-die kind of thing.
18:13:39 <drago01> notting: yeah we should slip by days instead
18:13:42 <nirik> the problem with moving from week to week is: do we have some kind of realistic way to estimate when we might be ready? I fear we dont.
18:13:44 <mjg59> Look
18:13:44 <pjones> notting: indeed.  I don't particularly think it is.
18:13:50 <rbergeron> but yes, after a while, it starts to become a bit weary on everyone - reporters, readers, etc. - how do we not have a better picture of just how long the delay is going to be
18:13:55 <mjg59> If people actually did some fucking work on fedup it would be ready in a week
18:14:18 <mmaslano> did you follow up with them?
18:14:21 <pjones> drago01: we really don't need sarcastic comments that aren't even trying to be productive.
18:14:25 <mmaslano> jreznik: you have some status, don't you?
18:14:40 <adamw> nirik: again the problem there is that we block on wwoods. we asked him several times for realistic timeframes on fedup and got answers that have proved to be inaccurate.
18:14:47 <jreznik> rbergeron: that's my question - are we willing to commit to some deadline even it would lead to lower standard release (not shiping junk but with some rough corners)
18:14:54 <mjg59> Oh for the love of god
18:14:56 <mjg59> This is pointless
18:14:58 <adamw> given that fedup has no other official developers and apparently no public development plan, i don't see what the hell else there is to do in estimating when it'll be done.
18:15:32 <jreznik> mmaslano: hard to get status, trying to nag every few days...
18:15:39 <nirik> right, so, given that it's very hard to say: Oh, lets slip 4 weeks and it will be ready then... without just completly guessing.
18:16:05 <rbergeron> can someone work with will to actually go through and identify what is remaining and what other people can work on?
18:16:06 <pjones> nirik: but even doing that would effectively reduce the amount of BS overhead we're *causing*.
18:16:07 <drago01> pjones: that wasn't sarcasitc ... my point is we shouldn't add a week everytime we think it isn't ready ... as long as it isn't a weekend I see no reason to to release on a monday for example
18:16:08 <t8m> mjg... that was childish a little bit.
18:16:13 <limburgher> And obviously we'll be looking out for single-person blockers in the future, but that doesn't help us get this out the door.
18:16:14 <drago01> it does not  have to be a tuesday
18:16:14 * jlk notes it would have been better to not enter the freeze in the first place, until the code was ready to be tested for beta status.
18:16:21 <jreznik> rbergeron: I'm trying to...
18:16:28 <adamw> the other factor is obviously anaconda, i know there's some sentiment in anaconda team for unfreezing and doing more development, so you could ask them whether they officially want that, and if so, how long.
18:16:37 <drago01> pjones: so just "ship once fedup is ready" rather then "keep adding weeks while it isn't"
18:17:02 <tflink> drago01: that adds overhead of status updates and/or meetings every day
18:17:08 <jlk> drago01: more like "once fedup, anaconda, secureboot is ready"
18:17:14 <nirik> jlk: we did delay, but it looked like fedup was going to be testable...
18:17:28 <t8m> adamw, that looks like a good plan
18:17:31 <nirik> proposal: keep to plan for now, revist next week.
18:17:34 <notting> *nod*, we didn't freeze until we thought fedup was going to be ready. it wasn't.
18:17:36 <jlk> nirik: if I recall, none of the Anaconda team felt freezing at that point was a good or useful idea.
18:17:37 <drago01> jlk: oh yeah
18:17:52 <nirik> jlk: I don't recall them saying that, but perhaps I missed it.
18:17:57 <t8m> nirik, -1
18:18:02 <notting> nirik: kind of -1
18:18:03 <jwb> i recall them saying that.  i also recall me saying that
18:18:05 <drago01> tflink: a ticket is enough for that
18:18:08 <mmaslano> um where did the discussin with anaconda team happened?
18:18:23 <jlk> yeah, we weren't exactly asked.  Except by jwb
18:18:31 <pjones> nirik: -1.  the plan sucks and has not been working for us.
18:18:33 <mitr> If we don't keep the current plan, given marketing doesn't want Dec 22, we are effectively slipping to January, aren't we?
18:18:43 <mmaslano> I guess we are
18:18:44 <nirik> t8m / notting: alternative proposals?
18:19:09 <jlk> unfreeze until we're ready
18:19:15 <jlk> freezing just makes things /harder/ to get out
18:19:23 <t8m> nirik, get some (not sure how realistic) estimate from anaconda team for how long they'd like to unfreeze
18:19:24 <adamw> i think jlk also hit a point that maybe hasn't been discussed enough: secure boot
18:19:25 <nirik> at least jan 8th if we are slipping more than a week
18:19:25 <drago01> mitr: we had enough slips already ... we don't need a "marketing slip"
18:19:36 <limburgher> jlk:  Will unfreezing make wwoods' work materially faster?
18:19:45 <notting> we have one week of play in the schedule, which we're going to hit tomorrow
18:19:47 <jwb> adamw, ?
18:19:49 <wwoods> no.
18:19:51 <jlk> it can increase the speed in which built packages get out to users to test
18:19:53 <nirik> notting: right.
18:20:05 <adamw> jwb: the SB folks rather think SB should be working in Beta, if I'm understanding correctly.
18:20:06 <mmaslano> blocker bugs will go to f18 anyway, so why unfreeze?
18:20:07 <jlk> however, I gather wwoods may be blocked on other people, so I don't know if that'll make it faster.
18:20:08 <limburgher> jlk: Just shortening the loop, then.
18:20:12 <notting> so, we are essentially assuming Everything Will Be Alright next week
18:20:13 <mitr> jlk, adamw: IIRC the freeze was there, in effect, mainly to help anaconda have a stable base.  If anaconda doesn't want a freeze, we probably shouldn't have one
18:20:14 <tflink> unfeezing also frees up a bit more qa time - we don't spend as much time with the blocker process
18:20:14 <rbergeron> look, if we have to do dec. 22, we do and suck it up, though the 22nd is a saturday (i thought the alternative was the 23rd?), and maybe pull together a plan to keep beating the drum through the holidays.
18:20:16 <jreznik> jlk: how do you define ready?
18:20:20 <jwb> adamw, yes.  and?
18:20:24 <jlk> limburgher: also drastically shortening the loop for Anaconda.
18:20:35 <rbergeron> that said i think it's just as silly that we couldn't do a release on jan. 3, dec. 27, etc.
18:20:37 <adamw> jwb: is it officially FESCo policy that we're holding the Beta for SB?
18:20:38 <rbergeron> rather than mid-jan.
18:20:50 <adamw> jwb: if so then that's fine, i just hadn't caught that
18:20:59 <wwoods> the currently-filed fedup blockers are, AFAICT, systemd and/or plymouth problems.
18:21:05 <jwb> adamw, ah.  ok, a fine question.
18:21:14 <mmaslano> adamw: I wouldn't say so
18:21:16 <jreznik> wwoods: I asked systemd guys to take a look
18:21:19 <mitr> adamw: We don't really think about SB AFAICT.
18:21:35 <jwb> some of us do
18:21:36 <mitr> It's in the background, but anaconda is more visible
18:21:38 <drago01> mitr: why? it is a feature that is not testable so ...
18:21:43 <jwb> untrue
18:21:44 * halfline perks up
18:21:52 <adamw> jwb: because as far as release validation goes, we're kicking the ball firmly to your side. we're not taking SB bugs as blockers under the validation/blocker process, but we've specifically noted that FESCo could decree that the Beta must be SB-able under the feature proces.
18:21:56 <halfline> wwoods: are you blocking on me for something?
18:21:57 <nirik> rbergeron: so non tuesday/partial week days for release are on the table? not sure how much it helps, but it could I suppose.
18:22:09 <mitr> drago01: AFAIK it is held by lawyers, so we can't do much
18:22:11 <jwb> adamw, ok, you punted.  that's fine
18:22:23 <adamw> jwb: yeah, so it's entirely up to fesco under feature process.
18:22:27 <drago01> mitr: does not change anything
18:22:46 <jwb> drago01, it's certainly testable to a degree.  i've been doing it for 2 weeks
18:22:47 * nirik notes 'held by lawyers' also makes it impossible to say when it will be finished.
18:23:11 <notting> rbergeron: problem with a jan. 8 release (by current schedule) is it means RC compose on 12/26
18:23:12 <rbergeron> nirik: it could, i just worry about the "23rd" being a sunday, wire basically being offline, noise going right into christmas eve/christmas. people aren't in the office, press folks aren't in the office, things are dead.
18:23:13 <jwb> particularly that whole "must work without the MS key" part that the board insisted was important
18:23:13 <limburgher> nirik:  So we really need to focus on what we can actually do something with.
18:23:16 <drago01> nirik: ... talk to them?
18:23:24 <jreznik> nirik: that's the thing - do we want to block on legal? can we set a deadline for legal?
18:23:42 <nirik> no.
18:23:46 <rbergeron> though i stlil worry about "bugs even getting fixed" while people are on holiday/vacation/planes/whatever
18:24:07 <nirik> proposal: sb 100% complete not a beta blocker.
18:24:16 <pjones> nirik: -1
18:24:16 <jreznik> notting: RC composes actually are based on the the clean blocker bugs list, /me would prefer to have a deadline for compose... adamw can explain current process
18:24:40 <notting> drago01: let me just state for the record that the lawyers are being talked to. a lot. (sorry, can't go into details)
18:24:40 <adamw> yeah, the RC compose date is entirely notional at this point. we should probably take it out of the schedule.
18:24:53 * nirik guesses he should stop, everyone hates my ideas. ;)
18:24:58 <notting> adamw: fine, then a final change deadline of 12/24, which is the same issue
18:25:03 <mmaslano> nirik: +1 I wouldn't block a release on that
18:25:18 <tflink> notting: change dealine of 12/24, we ship no matter what at that point?
18:25:25 <mmaslano> rbergeron: so, you would prefer January?
18:25:35 <notting> tflink: i'm seeing what a 1/8 release would mean in terms of schedule
18:26:14 <t8m> pjones, what does sb 100% complete mean? shim signed and thus no further changes to shim in F18?
18:26:16 <rbergeron> mmaslano: from a "get the word out perspective," yes - otherwise we're releasing and nobody's paying attention and by the time the universe is back at their desks it's old news
18:26:28 <notting> tflink: and it looks like it would mean at least some sort of required QA/releng activity across the week of 12/24
18:26:48 <pjones> t8m: it doesn't necessarily mean no further changes, but it /does/ mean it's signed so that beta media will boot on windows 8 machines out of the box
18:26:59 <jreznik> notting: yep, for Jan 08 it would require work during holidays
18:27:01 <adamw> notting: i'll show up for anything but christmas day...
18:27:03 <rbergeron> if we can work around odd dates over the holidays - assuming people might be willing to "do things" over the holidays, which ... is questionable (but i have to think some people might be willing to do things)
18:27:11 <rbergeron> adamw: you and me and vodka, baby
18:27:16 <pjones> t8m: once legal comes through (don't get me started) we should be able to sign bugfix updates as often as we'd like, plus a day or two of lag.
18:27:26 <t8m> pjones, OK
18:27:37 <tflink> notting: I was more worried about the concept of having a hard deadline for release but it looks like I may have misunderstood you
18:27:50 <rbergeron> but even if we have the people willing to do the work it says nothing about the people willing to fix bugs that are blockers that would allow us to ship
18:28:01 <jreznik> rbergeron: exactly...
18:28:10 <t8m> rbergeron, +1
18:28:22 <mitr> pjones: Is there a reasonably possible way to add SecureBoot support after GA?  (e.g. special boot.iso)?
18:28:31 <jwb> rbergeron, we have provenpackager for that
18:28:46 <adamw> jwb: sometimes blockers can be pretty domain-specific.
18:28:51 <adamw> jwb: we have a current example, after all. :)
18:28:54 <rbergeron> yeah.
18:28:57 <pjones> mitr: we could build one-off isos, sure.  the question isn't if we can build it.  the question is if we can get people to test it.
18:29:03 <adamw> (anyone seen Jes?)
18:29:05 <nirik> jwb: although kernel/grub2/shim need specific folks now. ;)
18:29:09 <pjones> mitr: and the best way to get them to test it is to make testing it the default
18:29:19 <rbergeron> adamw: precisely. can we apply someone's provenpackager status to solving the fedup problem? :)
18:29:36 <pjones> rbergeron: not sure how that's in any way related.
18:29:37 <adamw> rbergeron: i was thinking of the RAID bug, but n/m.
18:29:46 <jwb> nirik, what?
18:30:03 <drago01> rbergeron: it does not need packing it need development
18:30:07 <nirik> jwb: only people in the koji group can build official builds of those.
18:30:10 <notting> so, spitballing proposal of adjusted schedule: unfreeze now. discuss beta freeze next week with proposed beta ship of 11/27. final change deadline of 12/21 (yes, friday). start RC process then. ideally ship 1/8. if we don't hit beta freeze, then we move final ship to 1/15, and final change to 12/31 or so
18:30:14 <jreznik> adamw: yep, for RAID we are currently blocked on Jes in Barcelo, he replied to me today...
18:30:23 <pjones> nirik: sure, but there are enough of us that that shouldn't be an issue
18:30:50 <t8m> notting, +1
18:30:52 <notting> although i am concerned about unfreezing causing more blockers to be generated by change
18:30:53 <jreznik> notting: well, I can't say I like "slip forever" part
18:31:04 <rbergeron> drago01: yes, and usually bugs don't need packaging, they need development / eyeballs from someone who knows the code and not someone who has to familiarize themselves for a week to fix something
18:31:05 <mmaslano> notting: I wouldn't unfreeze. Let's only fix blockers
18:31:11 <rbergeron> but i could be talking out my ass, it happens a lot
18:31:33 <jreznik> currently freeze is problem only for anaconda
18:31:35 <notting> jreznik: we're going to slip until it's done anyway.
18:31:52 <notting> jreznik: fine then:
18:31:56 <jlk> it's also a problem for every other packager that's fixing bugs that aren't considered "blockers"
18:32:00 <jreznik> so we can work closely with anaconda to allow them "like unfrozen" development?
18:32:03 <notting> proposal: anaconda/lorax granted exception to be moved to stable by releng
18:32:06 <t8m> mmaslano, the problem with long freeze is that it alienates the other developers
18:32:22 <mmaslano> who can work in rawhide
18:32:26 <jreznik> jlk: not sure we really have such a big number now of non anaconda packages
18:32:29 <adamw> right, i don't see that it makes any sense to freeze everything except anaconda.
18:32:33 <jlk> it also does create issues for anaconda, when content in testing != content in stable
18:32:49 <dwmw2_gone> IS there any progress on fixing CVE-2012-3411 before release? Bug 833033, remote DoS unfixed since June. Please could FESCo prod the maintainer...
18:33:13 <nirik> dwmw2_gone: off topic much? ;)
18:33:18 <adamw> freeze isn't just to give anaconda a stable base, or even _mainly_ for that. freeze is supposed to be so we can reliably build and validate composes without churn. from that POV, the _most_ important thing to have frozen is anaconda and similar critical packages.
18:33:32 <pingou> freeze only critical path ?
18:33:43 <mitr> notting: The proposal for adjusted schedule sounds good to me, with the caveat that if devel is not done by end of year, we absolutely need to look at either dropping update support, or reverting anaconda ro something.
18:33:49 <nirik> so, lets try this from another angle...
18:33:50 <dwmw2_gone> nirik: sorry. I was going to wait until the any other business phase... but I'm 99% likely to be interrupted by baby by then so it was fairly much now or never.
18:33:54 <pjones> mmaslano: sure, but right now they're presumably accumulating bugs that should legitimately be at least NTHs
18:33:54 <mitr> pingou: Do we have tooling?
18:34:05 <pingou> mitr: tbh, not that I know :/
18:34:07 <nirik> change of slipping another week: everyone agrees this is very high right now?
18:34:16 <adamw> if we're going to unfreeze at all we need a reasonable rationale for doing so and for how long to do it.
18:34:23 <limburgher> nirik: <nods>
18:34:24 <nirik> chance of slipping 2 weeks is ? (completely unknown, ? )
18:34:26 <notting> nirik: jreznik says so, so i have no reason to doubt him
18:34:28 <jreznik> adamw: yep
18:34:33 <nirik> adamw: +1
18:34:54 <notting> adamw: the 'unfreeze' part of my proposal can be considered separately from the schedule portion
18:34:54 <nirik> dwmw2_gone: I can take a look at some point.
18:34:55 <pjones> nirik: I'd say it's a near certainty, yes.
18:34:59 <dwmw2_gone> thanks
18:35:01 <adamw> nirik: if we ignore the SB question, we have two unaddressed blockers (RAID and vt1) plus the fedup mess.
18:35:28 <jreznik> we can get jes working on RAID on Friday... + vt1 + fedup
18:35:35 <adamw> fixing two unaddressed blockers shouldn't take a week. so on the topic of known knowns, i'd say only one week. but other stuff can come up. to an extent it feels like the more we test anaconda, the more blockers we find.
18:36:04 <adamw> not to spread the discussion out more, but that is one thing that worries me. i'm not convinced there aren't fundamental flaws in the current anaconda codebase.
18:36:09 <jreznik> adamw: yep, that's what I said - were should be some point to create RC...
18:36:11 <pjones> adamw: that sortof sounds like the definition of QA :)
18:36:26 <notting> mo' testing, mo' problems.
18:36:26 * nirik is back to my first proposal which everyone hates. ;)
18:36:27 <adamw> it doesn't have much protection against crashing - there's no 'sanity layer' in partitioning. and we seem to _keep_ hitting problems with threads.
18:36:47 <adamw> there was a comment in #anaconda yesterday to the effect of 'let's dump the threads for f19'.
18:36:55 <adamw> which doesn't seem to augur well for the stability of f18.,
18:37:08 <jlk> way to take that out of context
18:37:15 <jlk> that wasn't in any way an actual suggestion
18:37:24 <adamw> jlk: oh, sorry
18:37:29 <adamw> but still, we do keep hitting problems with it.
18:37:30 <notting> ok, so:
18:37:52 * nirik is trying to look at nottings proposed dates.
18:37:59 <adamw> pjones: sure, but it's just that usually, when we've been frozen for two weeks, we hit a point where we stop finding problems. that doesn't seem to be happening.
18:38:07 <adamw> or at least, we stop finding *blocker* problems.
18:38:15 <notting> refined proposal: stay frozen. slip beta *two* weeks. (planned release, 11/27). move final change deadline to 12/21, with release date of 1/8. if beta slips further, final change 12/31, release 1/15. can do per-week after that
18:38:44 <t8m> I'd really prefer unfreezing at this point
18:39:13 <pingou> t8m: when do you propose to freeze again then?
18:39:17 <nirik> notting: so, what does that gain us over a 1 week slip now and just doing that if there's an additional week?
18:39:27 <jlk> I would propose a meeting to attempt a freeze in 2 weeks
18:39:41 <jlk> if the features aren't ready, don't freeze.  If they are, freeze.
18:39:51 <t8m> pingou, after 2 weeks or later if we don't decide to freeze
18:39:53 <adamw> jlk: if we unfreeze now, what would be the plan for anaconda?
18:40:03 <jlk> adamw: continued bugfix
18:40:08 <adamw> will we stay on the anaconda beta branch, or go to master and pull in all the 'post-beta' changes?
18:40:10 <adamw> okay.
18:40:11 <pjones> nirik: it gains us not pulling wwoods away to talk to him for two hours tomorrow to decide if he's done yet when we know he isn't because we're not giving him much, if any, actual help.
18:40:22 <pjones> nirik: same with the next week.
18:40:29 <jlk> adamw: we'd likely merge the master branch and keep working from it.
18:40:40 <adamw> kay.
18:40:41 <jlk> adamw: we aren't doing any post-F18 changes, everything is bugfixes
18:40:51 <nirik> pjones: you think people won't do that if we slip 2 weeks now? I'm suspecting they still will...
18:41:28 <pjones> also eliminates the point of the go/no-go meeting tomorrow (and next week) for the rest of us.
18:41:34 <t8m> nirik, at least they won't do that next week
18:41:39 <t8m> again
18:41:41 <notting> nirik: wwoods a change to breathe, an initial plan for how to deal with the holidays
18:41:48 <pjones> Also gives us some time on SB, which we could use since legal is being ... difficult.
18:41:48 <jlk> unfreezing also allows us to empty out the pending mess in bodhi
18:42:11 <adamw> if we're going to delay a couple of weeks i don't think there's a qa objection to a general unfreeze.
18:42:16 <nirik> notting: I'm fine with the plan, but if we only slip a week, we don't need it?
18:42:30 <adamw> f18 outside of anaconda has been fairly stable for the last few weeks, so i don't think it'd cause any major problems with validation etc.
18:42:34 * nirik notes nottings proposal doesn't have us unfreezing.
18:42:49 <adamw> nirik: well, i was just leaving the possibility open.
18:43:03 <t8m> we should vote separately on the schedule slip and on unfreezing
18:43:10 <Viking-Ice> adamw, we can just continue on the same path as we have been doing and planned on doing for final anyway
18:43:12 <jlk> adamw: are you counting updates-testing in with that?
18:43:22 <t8m> #proposal:  slip beta *two* weeks. (planned release, 11/27). move final change deadline to 12/21, with release date of 1/8. if beta slips further, final change 12/31, release 1/15. can do per-week after that
18:43:29 <adamw> jlk: yeah, i run updates-testing on my desktop and i compose a live from it every so often.
18:43:33 <pjones> t8m: ... and unfreezing first, because that could have schedule implications.
18:43:41 <jreznik> t8m: frozen?
18:43:48 <t8m> pjones, ok then
18:43:52 <nirik> wwoods: would slipping 2 weeks help you? or do you think the blockers are ourside fedup so it wouldn't matter?
18:44:07 <t8m> #proposal unfreeze with the implication of 2 week slip or more
18:44:10 <nirik> s/ourside/outside/
18:44:22 * t8m is +1 to unfreeze
18:44:39 * limburgher is +1 to unfreeze as well.
18:44:45 <jreznik> nirik: from what I understand, it's outside
18:44:55 <mitr> nirik: My imporession was that unfreeze would help primarily with things outside fedup
18:45:12 * nirik is unclear on what these 'outside' things are.
18:45:37 <pjones> nirik: https://admin.fedoraproject.org/updates/
18:45:49 <tflink> nirik: the major bug in the fedup process happens within systemd. it's possible that an issue in systemd or dracut could be causing it
18:45:59 <nirik> pjones: yes, I see them every day. ;)
18:46:02 <jreznik> if we unfreeze, we need a clear - when do we want to discuss freezing again, how, and especially to have a metric to unfreeze
18:46:08 <nirik> sorry, not that outside...
18:46:20 <nirik> those would be blockers, so the freeze shouldn't matter there.
18:46:28 <jreznik> nirik: yep
18:46:30 <t8m> jreznik, yes, but that can be discussed after the vote for unfreeze or not
18:46:35 <mitr> jreznik: "Full upgrade process determined and implemented, or we decide not to have an upgrade in F18" would be my suggestion
18:47:00 <adamw> also a decision on SB, similarly.
18:47:03 <mitr> Can we perhaps just vote on a 2 week slip now, to get it out of the way?
18:47:06 <jreznik> mitr: in two weeks?
18:47:15 <mitr> jreznik: whenever
18:47:30 <mitr> Until we know which one of these, we don't freeze
18:47:31 <jlk> We've decided (mostly) that anaconda, fedup, and secure boot are blocking features.  Ergo we should check with those feature owners in 2 weeks to determine if they feel we're done enough to enter Beta freeze and spin RCs
18:47:41 * jreznik is ok with 2 weeks slip now, not complete ok with "slip forever" part
18:47:44 <Viking-Ice> is there any reason we in QA cant contact fesco and simply say hey it's time not to slip anymore? basically slip until QA decides it's not necessary anymore?
18:48:04 <rbergeron> do they even think that two weeks is enough or are we just arbitrarily deciding this for them?
18:48:07 <mitr> jlk: One concern is that this didn't work out too well for fedup recently.
18:48:07 <nirik> Viking-Ice: we could, but the problem then is we have 0 idea of when release is
18:48:21 <pjones> jreznik: It's completely unclear to me how those are actually different in any terms but having more meetings.
18:48:23 <nirik> rbergeron: thats my question.
18:48:24 <mitr> nirik: Well we really don't have any idea.
18:48:25 <jwb> nirik, i really don't think that's a problem
18:48:28 <nirik> right.
18:48:37 <jlk> mitr: that was a "I think i'll be ready by then", not a "I'm ready now"
18:48:46 <jwb> working code, or lack thereof, is the problem.  once that's solved, we can figure out release
18:48:55 <pjones> jwb: plus one
18:49:07 <jwb> if we have to sit on working code for a week or two to avoid holidays or whatever, that is _easy_
18:49:08 <nirik> ok, lets roundup proposals so we get somewhere...
18:49:21 <Viking-Ice> nirik, is there some firm rules that says we need to decide now when the release will be or cant we simply punt that until we have stopped slipping ?
18:50:08 <nirik> a) do nothing, if we slip a week we do, etc. b) unfreeze now, freeze (tenative) 13th, beta 27th. c) don't unfreeze now, slip 2 week for beta on 27th.
18:50:32 <pjones> Viking-Ice: there's legitimate cause to want to know ahead of time - there are things that must be planned.  people need to know when they're going to get to visit their families on christmas.
18:50:42 <nirik> Viking-Ice: well, we in the past have been a '6 months per release' distro. If we want to move to a feature based schedule that would be something to discuss and change
18:51:07 <jlk> we've always slipped for features
18:51:15 <pingou> and we are
18:51:26 <nirik> sure, but we don't say: "Fedora 19 will be released with foobar is ready"
18:51:30 <pjones> jlk: which is to say we've always been really bad at being a "6 months per release" distro.  It has not served us particularly well.
18:51:32 <jlk> we've never shipped because "deadline was reached"
18:51:49 <rbergeron> feature creep is a problem when you are feature-based.
18:51:51 <jlk> nirik: right, we've been poor at communicating reality.
18:51:54 <nirik> jlk: we also haven't had "foobar delayed 6 months"
18:51:57 <rbergeron> or when you don't follow the rules of a time-based schedule.
18:51:57 <notting> i'm +1 to either b) or C) as stated by nirik above. not enthused about a)
18:52:01 <jlk> rbergeron: not when you clamp the accepted features early in the cycle.
18:52:11 <jlk> we're a combo of both.
18:52:13 <rbergeron> jlk: precisely (rules of a time-based schedule)
18:52:24 <tflink> what about how to decide on when to re-freeze, or is that to be discussed later?
18:52:27 <jreznik> jlk: currently we are combo of both...
18:52:29 <jlk> rbergeron: but we don't ship just because the clock stopped.  We ship when the code is ready.
18:52:36 <rbergeron> yep.
18:52:38 <pjones> notting: that's.. december 13th? re-freezing tuesday doesn't seem that different than slipping a week.
18:52:42 <nirik> I like a personally, because I am still not convinced an extra week now will really help out that much. Would stakeholders be able to provide more info on that?
18:52:48 <jreznik> tflink: if b) is chosen, then talk how to unfreeze again
18:52:50 <Viking-Ice> tflink, unfreeze for two weeks should suffice
18:52:52 <mitr> +1 to b) or c) as well,
18:53:08 <jreznik> well - guys a), b) or c) - if b) - how to unfreeze?
18:53:15 <mmaslano> let's vote finally
18:53:17 <nirik> do we know an extra week helps? how about 3?
18:53:20 <mmaslano> +1 to b or c
18:53:21 <notting> pjones: dec. 13 for what?
18:53:23 <tflink> Viking-Ice: what are you basing that assertion on?
18:53:27 <t8m> +1 to b)
18:53:38 <limburgher> b +1
18:53:43 <Viking-Ice> jlk's previous comment
18:53:48 <Viking-Ice> tflink, ^̂
18:53:49 <pjones> notting: the "b)" option you said you're okay with.  it says "13th" without a month.  I'm wondering if you're actually saying you're for a 6-day unfreeze.
18:54:12 <nirik> pjones: that was my optioning... and yeah, I had it there because thats two weeks before beta....
18:54:19 <nirik> that would clean out updates, no?
18:54:20 <notting> pjones: b) is unfreeze now, freeze in  a week, if i read it right
18:54:20 <t8m> I think that 6-day unfreeze is too short though
18:54:52 <pjones> so... that's pretty much just slipping 3 weeks and having a 1-week moritorium on blocker status.
18:55:06 <notting> if the issue is pending items, unfreeze doesn't need to be long. if it's continuing development, taht's a different issue
18:55:22 <t8m> btw seems that b) already got +5
18:55:31 <jreznik> guys, from clumens: [19:53] <clumens> jreznik: for anaconda proper, it looks like we only have one open blocker, so i don't think it matters to us.
18:55:51 <mmaslano> t8m: ok, we have a decision!
18:55:52 <jreznik> so it's more for fedup, sb
18:56:01 <nirik> pjones: well, slipping 2 weeks actually.
18:56:04 <adamw> jreznik: well i mean freeze or unfreeze doesn't affect fixing blockers at all
18:56:04 <nirik> for beta.
18:56:05 <drago01> just a though but can we try to have less time between beta and final?
18:56:16 <drago01> and if stuff explodes move final back?
18:56:19 <nirik> drago01: we already did cut a week from there. ;)
18:56:24 <drago01> oh
18:57:04 <t8m> We should not aim for final release in Dec - this is not realistic.
18:57:17 <mitr> We should perhaps look at putting it back there, if we are going to miss Decemer anyway - but let's leave that for a different time
18:57:31 <t8m> #agreed  unfreeze now, freeze (tenative) 13th, beta 27th
18:57:32 * nirik guesses he didn't add the rest of the slip there that notting proposed... did we also accept that?
18:57:32 <pjones> nirik: the 27th is 20 days from now.
18:58:12 <notting> just to clarify - is that also with the suggested final change deadline of 12/21, release on 1/8? or separate?
18:58:30 <nirik> so, on final, nottings proposal was: 12/21 final change, 1/8 for release?
18:58:38 <mmaslano> yeah
18:59:03 <mitr> sounds good
18:59:07 <nirik> that would mean folks would need to be around holiday week.
18:59:21 <nirik> as then rc's would be getting composed, testing, blockers
18:59:21 <t8m> #proposal final release schedule - 12/21 final change deadline, 1/8 for release
18:59:30 <jreznik> 12/21 is more than two weeks, isn't it?
18:59:43 <t8m> +1
18:59:45 <nirik> so, how about this:
19:00:16 <notting> jreznik: it is, but it's not as if we can move final two weeks from 12/11, and might as well use the sapce
19:00:16 <nirik> proposal: final change 2012-12-11, release 2012-12-18. ;) (here's where everyone -1's me)
19:00:17 <mitr> jreznik: IOW moving closer to the original schedule?
19:00:33 <mitr> nirik: yeah, -1
19:00:39 <t8m> nirik, yeah -1 :D
19:00:52 <mmaslano> -1
19:01:00 <notting> -1. makes me too nervous
19:01:18 <limburgher> That's awfully tight. . .
19:01:28 <nirik> ok, next proposal: final change 2012-12-18, release 2013-01-08
19:02:16 <limburgher> Better.
19:02:32 <nirik> this would give a week before holidays to do rc's/test/fix.
19:02:39 <nirik> if we can get it in the can before, great, lots of mirroring time.
19:02:47 <nirik> if not, people work over holidays.
19:03:13 <mmaslano> we are out of time, so +1
19:03:27 <t8m> if we really  release beta on 27th Nov then +1
19:03:31 <limburgher> +1
19:03:36 <jreznik_> sorry, got disconnected
19:03:48 <pingou> jreznik_: nirik | ok, next proposal: final change 2012-12-18, release 2013-01-08
19:04:06 <jreznik_> pingou: sounds better for me
19:04:14 <jreznik_> thanks pingou
19:04:45 <t8m> notting, nirik, mitr, pjones, ?
19:05:05 <notting> wfm
19:05:05 <nirik> or anyone else non fesco who would like to chime in
19:05:14 <pjones> I could be vaguely for that.
19:05:17 <mitr> +1 just to get this over with
19:05:30 <tflink> I think that might be a bit optimistic but not horrible
19:05:33 <mitr> I don't think the beta date is certain enough to worry about final change deadline honestly
19:05:51 <t8m> counting notting and pjones as +1 we have +6
19:06:05 <pjones> mitr: really does seem that way, yeah.
19:06:09 <t8m> #agreed final change deadline 2012-12-18, release 2013-01-08
19:06:10 <nirik> mitr: well, I think we need to decide that or the 2 week beta slip is kinda pointless.
19:06:21 <tflink> how are we deciding when to re-enter freeze for beta?
19:07:11 <nirik> dunno. could assume we will unless someone throws a red flag?
19:07:19 <nirik> and then if they do, discuss it then?
19:07:25 <mitr> nirik: Honestly I'll start intensely caring only in January (and then I'll propose just dropping upgrades or something equally drastic)
19:08:25 <nirik> tflink: would that work?
19:08:25 <t8m> let's move on to next topic - or is there something else to discuss for F18 schedule?
19:08:55 <t8m> btw #968 is automatically rejected I think
19:09:01 <tflink> nirik: so freeze would be discussed at the 2012-11-21 fesco meeting or on 2012-11-19?
19:09:24 <tflink> nirik: what would be considered a red flag, or is it left up to a judgement call?
19:10:05 <t8m> #info  #968 Move F18 release to no more than March 2013 is rejected by the vote on #960
19:10:14 <nirik> tflink: anyone thinks it's bad to enter beta freeze, file a ticket with fesco on the 12/13th and we discuss in ticket or have a special meeting?
19:10:25 <limburgher> Reasonable.
19:10:25 <t8m> nirik, +1
19:10:45 <t8m> #info anyone thinks it's bad to enter beta freeze, file a ticket with fesco on the 12/13th and we discuss in ticket or have a special meeting
19:11:08 <t8m> we don't need to vote on this I think
19:11:18 <t8m> next topic
19:11:27 <t8m> #topic #966 Fedora 19 Schedule proposal (DRAFT!)
19:11:36 <t8m> .fesco 966
19:11:39 <zodbot> t8m: #966 (Fedora 19 Schedule proposal (DRAFT!)) – FESCo - https://fedorahosted.org/fesco/ticket/966
19:11:51 <nirik> I think this may need reworking based on the f18 changes?
19:12:15 <t8m> nirik, +1
19:12:16 <pingou> maybe postpone this one until beta is out?
19:12:31 <t8m> pingou, that's good idea
19:12:45 <jreznik_> well, and do we still want to target May?
19:12:51 <jreznik_> reduce scope of F19?
19:12:58 <t8m> #proposal postpone discussion of this ticket until F18 beta is out
19:12:59 <nirik> yes, I would say so
19:13:37 <limburgher> +1, other than to say earlier feature submissions are better than late. :)
19:13:50 <jreznik_> limburgher: +1
19:14:18 <pingou> Feature submission start could be kept the same
19:14:19 <t8m> hmm but didn't we want to revamp the feature process?
19:14:30 <pingou> (do we really need such deadline?)
19:15:31 <mitr> t8m: at least some of the improvements (announcement, upgrade effects) would be good to have from the start
19:15:32 <limburgher> Not really.
19:15:49 <notting> (i apologize. i'm really not here right now, having been dragged into another meeting. will try and read up later)
19:15:49 <mitr> OTOH can we get it done soon enough?
19:16:12 <mitr> t8m: +1 to postponing
19:16:33 <mmaslano> ₊1 to postpone
19:16:47 <t8m> other votes to postpone?
19:16:56 * t8m is +1
19:17:06 <jreznik_> mitr: as I commented in the ticket
19:17:07 <nirik> yeah, +1
19:17:15 <pjones> +1 to postpone.  Also just like every other time I think this schedule is unrealistic.
19:17:33 <pjones> (And like this time, I will probably vote against it if it looks like this.)
19:17:39 <t8m> #agreed discussion of this ticket is postponed until F18 beta is out
19:17:49 <t8m> #topic #967 Proposal for automated Fedora packaging cleanup policy.
19:17:57 <t8m> .fesco 967
19:17:58 <zodbot> t8m: #967 (Proposal for automated Fedora packaging cleanup policy.) – FESCo - https://fedorahosted.org/fesco/ticket/967
19:18:08 <mitr> pjones: Could you suggest an alternative in the ticket, then, please?
19:18:08 <nirik> so, there's a lot of list discussion on this.
19:18:19 <jreznik_> pjones: well, what's the problem with proposed schedule, coudle fesco guys comment it in the ticket?
19:19:08 <nirik> I'd like to see about getting a script setup that just reports things, and we can adjust that... and then when everyone is happy with what thresholds it's reporting, we can see about policy around it?
19:19:25 <nirik> Viking-Ice: ^ how does that sound? get data first, then adjust and create the policy side...
19:19:29 <t8m> nirik, +1
19:19:29 <pjones> jreznik_: the problem is that it's ignoring the entirety of what's gone wrong this release and everything anybody has said here or elsewhere.
19:19:33 <limburgher> nirik: +1
19:19:40 <t8m> pjones, +1
19:19:44 <mitr> It seems to me that dropping "inactive" maintainers isn't really what we want that much.  Having people log in doesn't help the project any; having people ASSIGN every bug without doing anything on it doesn't help all that much either.  I think what we really need is some minimum maintenance standards.
19:19:49 <Viking-Ice> nirik, I'm fine with it
19:20:10 <t8m> mitr, +1 but can we define the standards?
19:20:24 <limburgher> mitr:  Which is admittedly difficult, but less arbitrary.
19:20:28 <nirik> mitr: right. I think one thing most people agree on is that we are poor at identifying maintainers who are completely gone...
19:20:28 <jreznik_> pjones: yep it is - are we really able to fix it automagically in time for f19?
19:20:38 <mitr> AFAICT Viking-Ice's concern is not people who don't log in, but people who don't update their packages to new standards. (Is that right?)  If so, we need to focus on the real requirements
19:20:39 <nirik> ie, it takes a long time and effort for someone to mark them inactive and take over, when our users suffer from the silence.
19:20:39 <pjones> jreznik_: well, certainly not if we just ignore it
19:21:00 <jlk> nirik: we're equally bad at finding developers who've essentially abandoned part of their packaging load
19:21:11 <jlk> while staying active with other packages.
19:21:12 <nirik> there's a number of cases here getting lumped together, IMHO.
19:21:32 <nirik> jlk: absolutely. Thats another case.
19:21:46 <pingou> instead of mark user inactive we could just grand co-maintainership more easily
19:21:46 <mitr> t8m: I'd suggest "3 things every package in $set must be updated for for the next release" (... with any package that doesn't comply being up for grabs).  Whether $set is "critical path", "default spin" or "whole distribution" or something else is a separate discussion
19:21:50 * nirik will try and add the cases he knows of to the ticket so we can gather data on them.
19:22:32 <pingou> if we manage to get rolling ftbfs check, that might help finding abandonned packages
19:22:32 <Viking-Ice> mitr, my main concern is that we stop rolling unmaintained packages between releases or deprecate/orphaning them to late in the development cycle so I would very much as early as we can in the development cycle to drop those packages so people are working only on bits that are actually being maintained in the release being developed
19:22:39 <mmaslano> why must be updated? some packages are simply perfect (or they have longer development time)
19:22:44 <nirik> a) maintainer gone, bugs unanswered, no comaintainers on their packages, b) maintainer busy, some packages less important getting less attention, etc.
19:23:05 <limburgher> mmaslano: +50
19:23:06 <nirik> pingou: only if they stop compiling.
19:23:07 <nirik> building != working
19:23:22 <pingou> nirik: that's a first filter
19:23:37 <pingou> nirik: we know how many fail that filter every time we do a rebuild
19:23:39 <mitr> c) maintainer working on some bugs, but not updating for e.g. systemd/systemd presets; d) maintainer that can't use the programming language the package was written in
19:23:55 <nirik> proposal: gather specific data/use cases, revisit.
19:24:17 <t8m> nirik, +1
19:24:20 <mmaslano> +1
19:24:22 <mitr> Viking-Ice: Hence my proposal for "3 things";  Would running the existing mass orphan cleanup process earlier resolve another part of your concerns?
19:24:24 <limburgher> +1
19:24:40 <nirik> mitr: those are very difficult to programatically determine or once you have do anything about.
19:24:59 <Viking-Ice> +1 nirik agreed start by gathering as much data as possible then work on a solution
19:25:36 <mitr> nirik: Determining them shouldn't be that difficult... and as for "do anything" - find a different maintainer or drop the package: if Fedora can't do the work, let's not pretend we can
19:25:50 <mitr> (or drop it from $set)
19:26:17 <nirik> mitr: oh? so, if I maintain a perl package you send me a perl test I must pass? ;)
19:26:25 <nirik> anyhow, enough votes/
19:26:26 <nirik> ?
19:27:07 <t8m> nirik, unfortunately not yet
19:27:33 <nirik> ok, counterproposals? more votes?
19:27:38 <t8m> nirik, if you give it +1 it is still +4 only
19:27:38 <Viking-Ice> mitr, with an identification process on unmaintained packages yes it probably would but let's first see how big the problem is ( me suspects first run is rather large $next_cycle maybe <10 components )
19:28:11 <mitr> +1 for now (assuming that ticket gets repurposed into a more generic "maintainer responsibilities" process - the current proposal is completely unattractive to me
19:28:25 <mitr> Viking-Ice: Hm, all the discussions for <10 components?
19:28:59 <t8m> so I see +5 if nirik votes for his own proposal
19:29:20 * nirik would
19:29:30 <pjones> +1
19:29:30 * limburgher is in Chicago, can vote more if need be.
19:29:47 <t8m> #agreed We revisit the ticket after we gather specific data/use cases
19:30:03 <Viking-Ice> mitr, no much more I'm afraid I just said ( probably not clearly enough ) that the cleanup process would identify a large set the first time it's run ( and that cleaned up ) but next release cycle ( as in f20 ) it probably would no be more then <10 components
19:30:11 <t8m> #topic Next week's chair
19:30:35 <mitr> Viking-Ice: ah, I misunderstood. Sorry.
19:30:35 * rbergeron sort of hollers that there is a board meeting imminnetly.. not sure if we should relocate or hang out a moment
19:30:50 <t8m> Anybody wants the chair?
19:31:13 <t8m> rbergeron, we will finish in a very short time
19:31:20 * rbergeron nods, i figured as much
19:31:30 <mmaslano> t8m: I can tak it
19:31:45 <t8m> #action mmaslano is the next week's chair
19:31:51 <t8m> #topic Open floor
19:31:59 <t8m> anything urgent for the open floor?
19:32:01 <mmaslano> https://fedorahosted.org/fesco/ticket/963
19:32:07 <mmaslano> nothing happened this week, so?
19:32:45 <t8m> mmaslano, well we unfreezed so he gets one more week to fix :D
19:32:53 <mmaslano> great ;-)
19:32:55 * nirik hasn't looked.
19:32:56 <mitr> mmaslano: would you just send a reminder/ask for status?  I don't think we can do much here.
19:33:00 <nirik> hopefully he's working on it.
19:33:04 <Viking-Ice> what did you expect to happen with that one ? was there a set of packages for him to work on?
19:33:08 <mmaslano> ok, I'll do it
19:33:19 <mmaslano> Viking-Ice: well I asked for revert
19:33:32 <mmaslano> anyway, it's long meeting, let's leave it for next time
19:33:42 <mitr> Viking-Ice: The working of the decision last time left identifying the packages to Kay
19:33:54 * pbrobinson is here
19:33:58 <mitr> s/working/wording/
19:33:59 <nirik> if he needs help, I'd be happy to help out.
19:34:14 <rbergeron> pbrobinson: they're wrapping up, we're up in a momento
19:34:23 <t8m> I'll end the meeting just now
19:34:26 * nirik has nothing for open floor
19:34:32 <t8m> #endmeeting