18:00:36 <mattdm> #startmeeting FESCO (2014-03-12) 18:00:36 <zodbot> Meeting started Wed Mar 12 18:00:36 2014 UTC. The chair is mattdm. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:36 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:42 <mattdm> #meetingname fesco 18:00:42 <zodbot> The meeting name has been set to 'fesco' 18:00:46 <mattdm> #chair abadger1999 dgilmore mattdm mitr notting nirik pjones t8m sgallagh mmaslano jwb 18:00:46 <zodbot> Current chairs: abadger1999 dgilmore jwb mattdm mitr mmaslano nirik notting pjones sgallagh t8m 18:00:50 <mattdm> #topic init process 18:00:52 <mitr> Hello 18:01:16 <mattdm> sgallagh noted that he can't make it; he voted in the tickets 18:01:24 <t8m> hi 18:01:28 <pjones> Hello, party people. 18:02:13 <nirik> morning all 18:02:31 <notting> good morning/afternoon/evening 18:02:49 <jreznik> hi guys! 18:03:10 <pjones> morning, notting@redhat/notting. 18:03:22 * mattdm waits a few more minutes for abadger1999 and dgilmore 18:03:34 <abadger1999> greetings 18:04:51 <mattdm> okay, so, many many topics this week. let's try to go fast :) 18:04:58 <mattdm> #topic Followups 18:04:59 * jreznik has to leave earlier but will follow meeting on smartphone and will act on Changes 18:05:01 <mattdm> #topic #1178 Fedora 21 scheduling strategy 18:05:08 <mattdm> .fesco 1178 18:05:09 <zodbot> mattdm: #1178 (Fedora 21 scheduling strategy) – FESCo - https://fedorahosted.org/fesco/ticket/1178 18:05:39 <mattdm> jreznik? 18:05:49 <nirik> so, one other thing we need to add: mass rebuild... (if needed) 18:05:49 <jreznik> so this is what I got when I played with schedule - aiming on Oct 14th... 18:06:09 <nirik> we want those at least 3 weeks before branching I think. 18:06:27 <jreznik> nirik: good point - we should know once we go through changes proposed 18:06:39 <nirik> yeah. 18:06:49 <jreznik> and there are three months for that 18:06:53 <nirik> just something to keep in mind... I think we already have the format-security thing that wanted it. 18:07:17 <jreznik> would be nice to have Change page for that - so it will be tracked 18:07:26 <notting> nirik: i was confused by that, though - it's just swapping a warning for an error. a mass rebuild won't actually apply anything to make it more secure 18:07:31 <nirik> good idea. there's a ticket on it. 18:07:55 <nirik> notting: true, although I guess it would make maintainers more aware that their package needs fixing? 18:07:58 <jreznik> so far I talked to QA - you can see in comment 35 - they seems to be ok with alpha to final timing 18:08:15 <nirik> so, really we need some sort of 'mock rebuild' that does it all, but just tells people failures. 18:08:16 <jreznik> should work for websites guys to prepare for next too 18:08:36 <t8m> I would avoid mass rebuild if the only reason is the format-security 18:08:45 <mattdm> nirik so should we just add a mass rebuild to the schedule three weeks before branching? 18:08:58 <mattdm> (and then not do it, if there turns out to be no need?) 18:09:06 <jreznik> and it's still no earlier than - I'd like to commit to the schedule once we go though the changes proposed... 18:09:19 <nirik> mattdm: if there are changes that need one and need coordinated. Might be a month before to be safer... 18:09:29 <jreznik> mattdm: I can definitely add it there as optional item 18:09:36 <t8m> do we know of anything else requiring mass rebuild? 18:09:42 <jreznik> t8m: not yet 18:09:48 <mattdm> jreznik +1 do it :) 18:09:54 <nirik> anyhow, thats a detail... I guess I am +1 to the proposed schedule... we really don't have detailed info on everything, but when do we ever. 18:09:57 <t8m> if it is marked as optional then +1 18:10:07 <t8m> and I am +1 to the schedule as is 18:10:35 <mattdm> proposal: accept provisional schedule with "no earlier than" labels; will make firm after change submission deadline. 18:10:39 <mitr> +1 18:10:50 <notting> jreznik: if QA is ok, that's good. websites would be a big concern, and releng 18:10:51 <jreznik> as I said - it's still "no earlier than", more to help people to plan, we can adjust it later once we have more details 18:10:57 <jwb> fwiw, this puts us in the same situation as F20 did for the kernel 18:11:10 <mattdm> jwb new kernel due right at release? 18:11:22 <jwb> mattdm, crystal ball inaccuracy aside, yeah 18:11:35 <jwb> not a big deal. we can carry the current released kernel again 18:11:35 <jreznik> notting: I talked to shaiton, he thinks it looks ok to make new websites ready (for alpha, only parts are being ready) 18:11:36 <notting> jwb: unless there's a particular kernel feature we'd be waiting on, i'm ok with that - we get the new one eventually anyway 18:11:45 <pjones> yeah, what notting said. 18:11:48 <pjones> mattdm: +1 18:11:50 <abadger1999> +1 18:11:54 <notting> +1 18:12:10 <jwb> notting, right. i'm fine with it. i just want it noted so people don't ask me 87 times why we aren't shipping with the BLEEDING EDGE kernel 18:12:15 <nirik> +1 18:12:41 <abadger1999> gives us somewhere to start discussion and room to slip if we have to. 18:12:44 <t8m> mattdm, +1 18:12:50 <mattdm> #agreed accept provisional schedule with "no earlier than" labels; will make firm after change submission deadline. (+8,0,0) 18:12:54 <jreznik> jwb: that's the same with gnome and other stuff - you can never make everyone really happy but at least we can try and with crystall ball - who knows? 18:13:00 <jreznik> abadger1999: yep 18:13:11 <pjones> jwb: I think you're gonna get asked anyway 18:13:22 <jwb> pjones, i would like to refer to these meeting minutes 18:13:28 <jwb> scripted URL respnoses are easier 18:13:29 <pjones> right on. 18:13:45 <mattdm> #info proposed schedule does cut things close with expected new upstream kernel release 18:13:59 * jreznik is going to set reminder to ask jwb once the right time will come 18:14:12 <mattdm> jwb anything else you want to put in the meeting summary, info it :) 18:14:24 <jwb> mattdm, thx 18:15:08 <mattdm> #info FESCo is fine with shipping at-the-time current kernel, which will be then updated as normal 18:15:28 <mattdm> unless anyone strongly disagrees with that statement, and I don't think anyone does :) 18:15:38 <mattdm> anything else on this topic for now? 18:16:01 <jreznik> nothing from me 18:16:06 <mattdm> #topic #1243 Consider release blocking status of KDE spin(?) for Fedora 21 in .next decision-making 18:16:10 <mattdm> .fesco 1243 18:16:11 <zodbot> mattdm: #1243 (Consider release blocking status of KDE spin(?) for Fedora 21 in .next decision-making) – FESCo - https://fedorahosted.org/fesco/ticket/1243 18:16:22 <nirik> shall we defer this until they submit their product proposal? 18:16:43 <jreznik> nirik: I'd like to ask you to defer until it's proposed 18:17:06 <mattdm> +1 defer further 18:17:07 <notting> ok then, +1 to defer 18:17:18 <mattdm> should we take this off the meeting agenda until that point? 18:18:00 <jwb> erm 18:18:03 <t8m> +1 defer and take off the meeting agenda 18:18:04 <jreznik> also see my last comment - we'd like to help QA/other teams by providing resources to help them, not to pass more burden on them 18:18:06 <abadger1999> Hmm 18:18:09 <jwb> wait... 18:18:12 <jwb> why would you do that? 18:18:16 <abadger1999> We should be sure to ask adamw as well. 18:18:22 <adamw> ahoyhoy 18:18:23 <pjones> nirik: I'm not so sure that's meaningful 18:18:45 <nirik> what isnt ? defer? 18:18:48 <abadger1999> adamw: Since you opened the KDE status ticket... when would you need to know what we want by? 18:18:53 <Viking-Ice> jreznik, it's better that the SIG/WG handle this all withing their sub community 18:18:57 <abadger1999> By "you" I mean QA. 18:19:12 <pjones> nirik: in http://meetbot.fedoraproject.org/teams/fesco/fesco.2014-02-19-18.00.log.html#l-234 many of us agreed that we don't think we should accept new product proposals until this batch is either working or failing on its own; assuming many of us still think that, we'll have to consider this independently of their proposal. 18:19:12 <Viking-Ice> jreznik, since QA does not have resources to spare 18:19:16 <adamw> abadger1999: eh, i guess at least by the time we hit branch/tc1. 18:19:23 <abadger1999> Okay. 18:20:05 <nirik> pjones: I suppose. 18:20:07 <adamw> at that point we're going to have to pretty much draw up a priority list of all the things that need testing in an ideal world, and compare that to the resources we have. 18:20:09 <mattdm> As I understand it, any kde-based product would be for post-f21 based on what we've said already (and I think on what the kde people are saying).... 18:20:29 <mattdm> but that there is still interest in keeping the kde spin release blocking in some way. 18:20:34 <mattdm> is all of that accurate? 18:20:39 <adamw> and also see what we can get in the way of testing co-operation from WGs/SIGs/etc. 18:20:40 <jreznik> mattdm: well, we are working hard to propose it as early as possible to make f21 18:20:43 <mitr> mattdm: That understanding is's not obvious from ticket 1243 18:20:53 <abadger1999> mattdm: okay -- so looking at sgallagh's last comment on the ticket which I kinda agree with, we need to decide on whether the KDE *spin* should be release blocking hten. 18:21:12 <Viking-Ice> for the first if we are going to be release blocking the output of one WG then we should be release blocking on the output from all of them 18:21:13 <mitr> abadger1999: spin and/or Workstation subcomponent 18:21:16 <abadger1999> mattdm: heh, you type faster han me :-)t 18:21:26 <Viking-Ice> it's not fair we block on "workstation" but not on server or cloud 18:21:30 <jreznik> adamw: that's our idea, we want to help you, not to put more burden on you - test cases, test matrices etc. 18:21:34 <mitr> Viking-Ice: I think it's assumed that the Products are release-blocking 18:21:46 <Viking-Ice> mitr, we dont have resources for that 18:21:58 <nirik> Viking-Ice: would you stop saying 'we' ? 18:22:04 <adamw> Viking-Ice: mitr: i don't see we need to make any assumptions either way. we can make any choice we like (as a project). 18:22:07 <Viking-Ice> nirik, why 18:22:17 <Viking-Ice> we in QA dont have resurces for that 18:22:28 <nirik> Viking-Ice: because you don't speak for all of qa, unless I missed a meeting somewhere. 18:22:29 <drago01_> and wasn't one of the reasons to delay f21 to get resources in form of automation? 18:22:35 <Viking-Ice> nirik, neither does adam 18:22:35 <jreznik> Viking-Ice: then WGs has to provide resources and I think it's the way how WGs vs rest of Fedora should work... on other teams would create more framework for it 18:22:40 <nirik> Viking-Ice: indeed. 18:22:52 <Viking-Ice> nirik, or chris yet you refered to them as QA earlier 18:22:53 <adamw> all my 'we's at this point should be read as 'we, fedora' 18:23:00 <mattdm> +1 to "we, fedora" 18:23:14 <jwb> then just say fedora 18:23:16 <jwb> this shit is tiring 18:23:19 <mattdm> I am puzzled by a desire to partition off different groups into factions 18:23:26 <Viking-Ice> in anycase I'm pretty sure adam does not disagree with my statement 18:23:59 <nirik> look, we are going to try and do the best we can with the resources we have. 18:24:00 <drago01_> adamw: so does taskatron help us in any way here? 18:24:08 <mattdm> I think it's better for product wgs and various sigs to work with existing QA group for QA, including contributing resources 18:24:27 <mattdm> so that there is _overlap_, rather than division 18:24:46 <nirik> right. 18:24:52 <mitr> Viking-Ice: AFAICS we are going from $cloud + 1 netinstall + 1 ISO + 1 live to $cloud + 1 netinstall + 1 ISO + 1 live, it's not obvious to me that the minimal test set (does it install? does it not obviously crash?) is much larger 18:24:55 <adamw> drago01_: in its present form, not particularly, as the initial goal for taskotron is to replicate the functionality of autoqa only more reliably. that is, the first actual functional practical tests we'll have running in taskotron primarily help us produce more reliable *updates*. 18:25:16 <drago01_> adamw: ok fair enough 18:25:42 <nirik> anyhow, IMHO, we should block on products and their deliverables only. Other things like spins should be best effort. 18:25:49 <jreznik> mattdm: exactly 18:25:53 <adamw> we would like to automate some release validation tests in some way at some point, but i don't know if that's going to be viable in an f21 timeframe. 18:26:26 <mattdm> adamw good example -- some people in cloud sig are very interested in pluging into qa group to help with that. 18:26:34 <pjones> nirik: but how much effort are we willing to make best effort there? 18:26:39 <adamw> nirik: jreznik: all the things being said individually sound reasonable, but the upshot sounds an awful lot like 'we won't block on kde for f21'. 18:26:40 <mattdm> which should in turn benefit everyone. 18:26:53 <nirik> pjones: thats up to the sigs/maintainers/qa folks... since we wouldn't block... 18:27:01 <adamw> if we choose to say 'we will only ever block on Products' and we also say 'we can't add any more Products for f21'... 18:27:10 <nirik> adamw: right. 18:27:17 <adamw> okay. just making sure the implications are clear. 18:27:21 <pjones> nirik: so basically you're saying kde should set their own schedule that lands with plenty of time to spare ;) 18:28:12 <mattdm> I am okay with the idea of making a special exception for kde as a blocking but non-product spin for f21 18:28:19 <abadger1999> adamw: yeah, that's what I see as the upshot... I think I'm -1 to that outcome at this time. 18:28:23 <notting> while past performance is no indication of future results, how often in the past have we blocked/slipped due to issues in the KDE spin? 18:28:28 <mattdm> because of the historical status and to ease transition 18:28:30 <adamw> in terms of QA prioritization, FWIW, i see the two primary determining factors of how much we care about testing something as 1. is it release blocking? and 2. how prominent is it? (in terms of how heavily do we talk about it in PRs, how visible is it on download page, how many people actually probably use it, etc.) 18:28:32 <abadger1999> mattdm: I could go for that. 18:28:34 <nirik> pjones: no. I am saying that they should act just like lxde/xfce/mate/etc... they should try and be ready at the milestones. If they have bugs that need thru freeze, they propose them as FE's (not blockers), so things wouldn't halt for them, but they could get reasonable fixes in if given time. 18:28:41 <abadger1999> Or we could defer and talk more about this on mailing list. 18:29:05 <nirik> notting: good question. I know it's happened, but I don't think often 18:29:06 <adamw> notting: usually KDE has its stuff together pretty good and we knock out the major issues quite early. F20 happened to have a pretty icky blocker in KDE which got fixed pretty close to the deadline, IIRC. 18:29:11 <jwb> nirik, and if those bugs block a product because the product has stated KDE is required and blocking? 18:29:34 <nirik> jwb: then they would be blockers because they would be needed for a product. 18:29:51 <mattdm> jwb If desktop wg says that, then that neatly sidesteps the issue, yes. 18:30:00 <jwb> not exactly 18:30:02 <mattdm> but I think that puts us back to "defer", doesn't it? 18:30:04 <pjones> notting: adamw: eh, seems like we should just evaluate on a case-by-case basis 18:30:19 <jwb> because the install method is different between WS and KDE spin 18:30:22 <pjones> if we have a bunch of FEs for other things and one thing for KDE that they'd really like as a blocker, accepting it wouldn't be the end of the world. 18:30:25 <nirik> so the bad case would be: bug found in kde spin at the last minute, all products are already go, so no new rc's or whatever... means it would go out with the bug. 18:30:28 <adamw> just from my personal view of how releases go, i'd be quite optimistic that KDE SIG could produce a good F21 release without whatever 'benefits' come from release-blocking status, but there is of course a higher risk of us releasing with a major problem if we don't block. 18:30:35 <adamw> nirik: yup. 18:30:39 <notting> jwb: right, something breaking KDE on workstation may be different from something breaking KDE on the KDE spin 18:30:41 * jreznik would be ok saying, that only products are blocking, so let us to propose you what we're working on now 18:30:46 <Viking-Ice> just so people realize a bit how much work this is in QA we have spend around 2- 3 hours per blocker bug meeting which can be up to two to three per week and this is just dealing with KDE and Gnome being release blocking and granted that most time is spent in Anaconda 18:30:53 <pjones> nirik: adamw: right. And I'm just saying: do we really need to be hardliners about this? 18:31:26 <jreznik> adamw: and releasing broken KDE - as it has a huge userbase... 18:31:33 <mattdm> Viking-Ice excellent point; noted 18:31:57 <nirik> well, it just seems weird to me to make a spin release blocking... since it isn't important enough to be a product? 18:32:04 <adamw> pjones: it's nice to have clarity where it's possible. if we say case-by-case basis, i mean, what are we saying? we probably won't block on KDE but if something "really bad" happens we will? that gets very squishy. 18:32:04 <mitr> pjones: I think the question is: what do we _need_ to deliver in a release to make both the userbase and the contributor base happy? I cloud argue that "working KDE" is, in that sense, actually more important than "new Product features". 18:32:25 <mattdm> and that squishiness seems likely to take _more_ time and effort later 18:32:25 <t8m> mitr, +1 18:32:27 <pjones> adamw: I think the point of not leaving it defined that well is that we don't have to "get squishy", yes. 18:32:31 <nirik> if KDE is important, shouldn't it be a product? 18:32:33 <jreznik> nirik: that's why I ask defer until we propose a product... 18:32:45 <jwb> nirik, or included in an existing product 18:32:53 <abadger1999> nirik: Yeah -- so we're in transition right now. 18:32:56 <pjones> mitr: yes, that's a reason not to go all "all products all the time and nothing else" on it 18:33:04 <nirik> jwb: I suppose... 18:33:12 <pjones> I think from a practical point of view, KDE needs to work 18:33:13 <t8m> I think we didn't reject the idea of additional product before F21 release completely. 18:33:17 <mitr> nirik: IMHO, no. Product = influencing upstream direction, and Fedora-level structural decisions. Desirability has nothing to do with it in my view. 18:33:26 <adamw> pjones: if you're saying that it might be a good idea to block on KDE-as-a-spin for F21 just on the practical merits of where we've wound up: i'd agree with that. 18:33:36 <pjones> so we don't have to promote it to product immediately, because like abadger1999 says, we're in transition. But that doesn't mean we should just ignore that it's important, either. 18:33:42 <abadger1999> which means to me that what we do for f20 won't represent the ideal we're workign towawrds ... it represents a mix of the goals we're working towards and the reality of what we can accomplish before October. 18:33:57 <pjones> adamw: right. But the place to make that decision is basically: how bad is the bug in question? 18:34:04 <pjones> adamw: which we clearly don't know right now 18:34:08 <nirik> mitr: I think our KDE folks have influnced upstream... but thats drifting off topic I think. 18:34:17 <adamw> well, i mean, we have the release criteria for that. anyhow. 18:34:42 <pjones> yeah, sure. 18:35:08 <pjones> so I guess I'm really saying that I'm not in favor of abandoning kde's bits of the release criteria just because we're in the process of moving to a different model. 18:35:09 <mattdm> t8m I think we _did_ say that we wanted to do one release with these three products 18:35:11 <jreznik> nirik: well, kde folks are now pretty close to upstream and actually in some ways are steering where kde goes (sddm, nm-qt, solid, akonadi) 18:35:15 <mattdm> i'm trying to find the meeting logs 18:35:17 <notting> jreznik: is your not-so-theoretical proposal for f21 or f22? 18:35:40 <pjones> t8m: we didn't outright reject it, but we did defer until later with an eye towards only doing those three this release 18:35:40 <jreznik> notting: I hope for f21, we are progressing pretty fast - but it's up to fesco 18:35:48 <mitr> mattdm: linked by pjones earlier today 18:36:03 <t8m> mattdm, as pjones said - we didn't outright reject it 18:36:09 <mattdm> mitr in the ticket or in the scrollback here? 18:36:11 <pjones> http://meetbot.fedoraproject.org/teams/fesco/fesco.2014-02-19-18.00.log.html#l-234 <-- see again 18:36:14 <nirik> jreznik: when is the proposal going to be ready to submit to fesco? 18:36:20 <mattdm> pjones thanks 18:36:34 <jreznik> we are trying to prepare high quality proposal to convince you and I think we're on par with other WGs now 18:37:00 <jreznik> nirik: I think we can make it by next week (or two weeks), some people actually wanted to present it today 18:37:28 <jreznik> initial mission statements was agreed on, same for initial WG (from KDE SIG/Plasma WG side) 18:37:49 <Viking-Ice> do we need to complicate this cant we just say for F21 we keep KDE/Gnome block release blocking like they always have after for F22+ products onward only products will be release blocking which should give kde and rest of spins to work on product proposal? 18:37:52 * jreznik tried to ping other folks, but nobody is here now 18:38:13 <abadger1999> Proposal defer 1-2 weeks for KDE Product Proposal. If we don't approve that in two weeks we can revisit whether to make the KDE spin release-blocking. 18:38:22 <nirik> abadger1999: +1 18:38:44 <adamw> don't think that should be a problem for QA (we don't have to really ramp up f21 testing in the next two weeks) 18:38:49 <adamw> Viking-Ice: do you agree? 18:39:03 <mattdm> I agree with what Viking-Ice said 18:39:15 <mattdm> but am also +1 to abadger1999 because it is harmless :) 18:39:15 <nirik> I disagree. ;) 18:39:19 <t8m> abadger1999, +1 18:39:28 <mitr> mattdm: The implicatication that Products aren't release blocking is problematic 18:39:30 <Viking-Ice> adamw, I'm fine with it I'm more worried about what happens near the end rather then the beginning 18:39:31 <mitr> abadger1999: +1 18:39:31 <notting> is it a bad time to wonder what 'release blocking' even means in terms of multiple products, and can we move to a model where they don't need coordinated under that single framework? 18:39:35 <abadger1999> +1 18:39:49 <pjones> notting: I think that's been a longer term goal? 18:39:57 <jwb> notting, depends how long you want to stay in the meeting today 18:40:00 <nirik> notting: different release schedules is a big can ofworms. ;) 18:40:18 * pjones has another meeting in 2 hours that he'd really like an hour or so to prepare for :P 18:40:23 <abadger1999> notting: maybe we should have dgilmore present since he could tell us about some of hte releng entanglements that might make that difficult. 18:40:37 <notting> nirik: *nod*. but even the idea of 'cloud ships now, workstation ships in a week when they fix XYZ'. in any case, +1 to abadger1999's proposal 18:40:38 <Viking-Ice> notting, that is the way forward but when I discuss this in the serverWG I apparently was suggesting forking Fedora 18:40:42 <mattdm> notting maybe a bad time to consider it now. :) but it might make it easier if _spins_ were that way 18:40:44 <Kevin_Kofler> As a KDE SIG person, I'd really like to get the KDE spin approved as release blocking (as it has been for years) independently of the Product discussion… 18:41:32 * mattdm is counting 18:41:38 * pjones is also for making it block. 18:41:44 <nirik> notting: yeah, thats more doable than "freeze everything for server this week, unfreeze, freeze everything for cloud for a month" etc 18:42:06 <mattdm> we have at least five votes for abadger1999's proposal 18:42:07 <pjones> mattdm: I can be +1 to delaying the product decision that wasn't going to happen today anyway. 18:42:19 <mitr> pjones: I'm +1 to making $something block, but we don't need to box us into a "KDE spin" right now if there may be other proposals soon 18:42:37 <pjones> mitr: fair. but... looking for suggestions as to what thing that would be, you know? ;) 18:43:14 <pjones> mitr: And I think Kevin_Kofler's statement is pretty fair. 18:43:35 <mattdm> #agreed defer 1-2 weeks for KDE Product Proposal. If we don't approve that in two weeks we can revisit whether to make the KDE spin release-blocking. (+7,0,0) 18:43:44 <mattdm> i think that was the right count 18:43:47 <mitr> pjones: I'm somewhat skeptical but jreznik_ promises to surprise us, and we're not in a hurry :) 18:43:53 <mattdm> maybe i missed someone. :) 18:43:54 <Kevin_Kofler> mitr: Right now, our plans in the KDE SIG are that the primary deliverable of the Plasma Product will still be a live image. 18:44:00 <Kevin_Kofler> At least, as far as I am aware of. 18:44:15 <ltinkl_> good evening 18:44:42 <mattdm> it's been about half an hour on this topic -- I suggest we move on and continue discussion in mailing lists 18:44:46 <Kevin_Kofler> So that live image would be the replacement for the KDE Spin if the Product gets approved. 18:45:07 <mattdm> especially since we did just agree to defer :) 18:45:13 <mattdm> #topic #1230 Requesting FESCo address Cherokee logo issue 18:45:15 * nirik looks forward to the product proposal 18:45:20 <mattdm> .fesco 1230 18:45:22 <zodbot> mattdm: #1230 (Requesting FESCo address Cherokee logo issue) – FESCo - https://fedorahosted.org/fesco/ticket/1230 18:45:39 <nirik> abadger1999 did this change 18:45:48 <abadger1999> Yep, should be done now. 18:45:54 <mattdm> okay. so, nothing more to do here, moving on.... 18:46:02 <mattdm> #topic #1240 taking ownership of packages fityk and sundials 18:46:06 <mattdm> .fesco 1240 18:46:07 <zodbot> mattdm: #1240 (taking ownership of packages fityk and sundials) – FESCo - https://fedorahosted.org/fesco/ticket/1240 18:46:27 <mattdm> nirk? 18:46:31 <mattdm> nirik? :) 18:46:41 <nirik> I mailed the current owner... no reply however. 18:46:52 <nirik> proposal: just reassign packages 18:47:01 <t8m> nirik, +1 18:47:54 <abadger1999> nirik: +1 18:48:08 <mattdm> sure +1 18:48:47 <mattdm> anyone else? 18:48:55 <mattdm> any dissenting votes? 18:48:56 <notting> +1 18:49:45 <mattdm> #agreed Packages will be reassigned (+5,0,0) 18:49:47 <pjones> +1 18:49:49 <pjones> doh 18:49:52 <mattdm> #undo 18:49:52 <zodbot> Removing item from minutes: AGREED by mattdm at 18:49:45 : Packages will be reassigned (+5,0,0) 18:49:56 <mattdm> #agreed Packages will be reassigned (+6,0,0) 18:50:00 <nirik> either I or abadger1999 can do it after the meeting. 18:50:02 <mattdm> lol very important! 18:50:18 <abadger1999> <nod> 18:50:28 <mattdm> either of you want an action item? :) 18:51:10 <mattdm> whatever. moving on. :) 18:51:15 <mattdm> #topic New Business 18:51:17 <mattdm> #topic #1252 mesa 10.0.3 updates exemption for F20 18:51:20 <mattdm> .fesco 1252 18:51:21 <zodbot> mattdm: #1252 (mesa-10.0.3 for F20) – FESCo - https://fedorahosted.org/fesco/ticket/1252 18:51:50 <nirik> note that this is heading to stable already. ;) 18:51:56 <nirik> it would take something severe to stop it. 18:52:19 <mattdm> right, so as I mentioned in ticket, I don't think there's any likely reason to take severe action... 18:52:28 <mattdm> but by the policy, this should have been in testing for two weeks 18:52:35 <drago01_> well can we have some general exception for packages that provide support for new hardware? 18:52:41 <mattdm> because it is a critical path update 18:53:07 <drago01_> its not that bad because we allow kernel updates but asking user to wait a months before their hardware work is kind of a flaw in the policy 18:53:30 <mitr> mattdm: two weeks _or_ sufficient positive karma, and it got the karma 18:53:52 <nirik> right. what mitr said 18:53:53 <mitr> drago01_: No. Those packages are still expected to be non-disruptive. 18:54:12 <mattdm> oh sorry I misread the two-line boolean :) 18:54:23 <drago01_> mitr: what is "disruptive" in supporting new hardware? 18:54:33 <drago01_> mitr: there is no contradiction here 18:54:50 <mitr> drago01_: disruptive in the sense that is prohibited by the updates policy. If there is no contradiction then no exception is needed :) 18:55:28 <drago01_> mitr: well "version goes from 9.x to 10.x" seems to be considered disruptive by some people 18:55:51 <mattdm> drago01_ that's definitely a warning flag, but of course numbers are always different 18:56:12 <mattdm> I'm generally happy to trust the maintainers to know when there is a real risk of disruption 18:56:23 <abadger1999> drago01_: https://fedorahosted.org/fesco/ticket/1252#comment:2 this was more to the point than the version numbers to me. 18:56:25 <mattdm> and to not try to cheat that 18:56:26 <mitr> drago01_: In this case there _was_ an ABI break. That generally falls into the category of "disruptive". 18:56:49 * mitr apologizes for getting tied into the generalities 18:56:50 <drago01_> mitr: an abi that is not used by applications and affects packages maintaed by the same people 18:57:01 <jreznik> mattdm: about numbers, that was my point last time this policy was set... 18:57:29 <mattdm> drago01_ that is, distinction between public abi and internal abi. 18:57:32 <nirik> not used by applications? how can we know? it's a shared library... 18:57:35 <mitr> Proposal: This mesa update has an exception from the updates policy, given the unique situation (breaking ABI for a single user that has been updated). The policy as written is not modified. 18:57:49 <nirik> mitr: +1 18:58:23 <drago01_> nirik: because it makes no sense to be used by applicatiojns directly its a driver api 18:58:32 <abadger1999> mitr: -0.1 18:58:47 <mattdm> nirik, drago01_: and is in fact defined and documented in that way 18:59:05 <drago01_> mattdm: why are we having this discussion then? 18:59:12 <abadger1999> I don't want to fight that fight today but I'm generally of the thought that hte policy could be relaxed a bit more. 18:59:17 <mitr> Well, non-distribution drivers are... not unheard of :) 18:59:22 <t8m> mitr, +1 18:59:30 <drago01_> mattdm: i.e should not grant an expception but state that it does not require one instead 18:59:41 <mattdm> drago01_ exactly 19:00:11 <notting> mitr: +1 19:00:18 <mattdm> proposal: specific excemption not required because change is to internal abi only; update policy to make this clear 19:00:20 <mitr> abadger1999: I would support moving more towards the direction of "expect (and demand) upstreams not to break stuff, and do more rebases"; breaking library ABIs is not acceptable to me in general. 19:00:26 <t8m> or just close the ticket and move on :) 19:01:17 <drago01_> mitr: granting an exception would imply that one is required each time such an update is created 19:01:23 <mitr> mattdm: How would anyone know whether the ABI is internal or not? (We did have cases of upstreams saying "you shouldn't have been that anyway, it's your fault your applications broke") 19:01:31 <drago01_> mitr: and there seems to be an agrement that this is fine by the policy 19:01:38 <mitr> drago01_: Which is fine in this case because the library has gone away and AFAICS the case won't reoccur. 19:01:49 <abadger1999> drago01_: Well... no. I think that this isn't fine by the current policy. 19:01:50 <nirik> I'm no opposed to adjusting the policy, but I would prefer proposals and time before doing so, not ad-hoc in a meeting about another thing. 19:02:22 <drago01_> abadger1999: "<mattdm> nirik, drago01_: and is in fact defined and documented in that way" 19:02:23 <abadger1999> but I'd like it and more to be fine. (I think I'm in the minority about the "and more", though) 19:02:54 <abadger1999> drago01_: well.... agreement versus, consensus perhaps. 19:03:38 <mattdm> I'm not an expert in graphics drivers, mind you. That's just my quick impression in looking at it. 19:03:38 * abadger1999 notes that we could discuss this resolved issue more or move on and discuss the next time it comes up instead... 19:04:05 <mitr> Please. We don't need to agree whether this needs an exception because there won't be a next time. 19:04:36 <drago01_> mitr: "there won't be a next time." ? 19:04:39 <drago01_> mitr: why? 19:04:56 <drago01_> mitr: I can go and do a mesa 10.1 19:04:58 <mitr> drago01_: AFAICT libxatracker.1 was completely removed, wasn't it? 19:05:05 <drago01_> mitr: no 19:05:11 <mitr> Huh, sorry 19:05:20 <drago01_> so bump 19:06:10 <drago01_> mitr: "mesa-libxatracker-10.0.4-1.20140312.fc20.x86_64.rpm" is not an empty package 19:06:49 <notting> abadger1999: well, i have one minor additional proposal 19:06:49 <nirik> so, the reason we should decide this is if there is a next time they will know if they need an exception or not. 19:06:56 <nirik> unless we are going to adjust the policy before then. 19:07:07 <mattdm> nirik yeah. 19:07:51 <mattdm> notting proposal? 19:08:15 <notting> proposal: when filing an update exception request with fesco, make sure you turn off autokarma. 19:08:35 <drago01_> notting: he filled it because someone added a comment 19:08:44 <mattdm> I think that might be more an *info* than a proposal 19:08:52 <notting> drago01_: ... and he can still turn it off at that point 19:08:53 <abadger1999> notting: +1 19:09:00 <mattdm> #info when filing an update exception request with fesco, please make sure you turn off autokarma 19:09:01 <mitr> Proposal: libxatracker soname bumps are considered { an exception from the updates policy / a case where the policy is not applicable}, given the unique situation (a library with a single intended user) as long as the user of that library is updated in sync. The policy as written is not modified in other respects. 19:09:01 <drago01_> ideally you should ask before filing it 19:09:06 <mitr> notting: +1, clearly needed 19:09:33 <mattdm> mitr proposal +1 19:10:01 <nirik> notting: yes, +1 19:10:14 <abadger1999> mitr: If you clarify intended there I could vote =1 I think. 19:10:45 <abadger1999> The clarity being, we really really mean intended as opposed to "only user in fedora". 19:10:49 <nirik> intended -> single known ? 19:11:04 <abadger1999> nirik: I think that would be the opposite of what I'm getting at :-) 19:11:08 <mattdm> (if anyone really wants me to make nottings proposal into an "agreed" let me know quickly -- I don't think it needs it and teh info is sufficient) 19:11:11 <mitr> nirik: intended >> single known 19:11:17 <nirik> yeah, I don't know, just trying to read it and ... ok 19:11:19 <mitr> ("is a much stronger requirement") 19:12:19 <mitr> abadger1999: Could you propose a clarification? 19:12:20 <abadger1999> Actually I vote +1 anyway since it's about this specific case.. but if we add something about this to the policy, we should be sure to let people know that we do mean intended. 19:12:51 <mattdm> okay so that's +3 for, assuming mitr is. 19:13:02 <mitr> I'm +1 for the record 19:13:08 <t8m> mitr, +1 19:13:17 <mitr> (Do we need to update the updates policy for the autokarma note?) 19:13:46 <nirik> mitr: we should yeah. 19:14:19 <mattdm> #action mattdm to update policy with autokarma note 19:14:20 <notting> i'm fine with mitr's proposal - +1 19:14:21 <nirik> I can be +1 to that for this case... but it doesn't help clarify things moving forward much for others. ;) 19:14:41 <abadger1999> well, we're trying t obe clear about hte precedent that we're setting. 19:15:07 <abadger1999> I think it's something along the lines of "an internal library" 19:15:33 <abadger1999> but my brain isn't currently up to the task of defining that :-) 19:15:39 <mattdm> do we want to narrow down which of the two options we're calling this? ( an exception or a case where it doesn't apply?) 19:15:48 <mitr> I don't really think this is an interesting precedent to set... if we wanted to solve the real problem, we would be defining the user-facing API/ABI by _white_list, not by blacklisting corner cases. 19:15:52 <mitr> mattdm: I don't :) 19:16:04 <mattdm> okay then :) 19:16:12 * abadger1999 would rather just move on for today :-) 19:16:22 <mitr> (... and I'm not ambitious enough to define such a whitelist this year, to be clear) 19:16:25 <nirik> yeah, do we have enough votes to approve mitr's and move on? 19:16:52 <mattdm> #agreed libxatracker soname bumps are considered an exception from the updates or a a case where the policy is not applicable, given the unique situation (a library with a single intended user) as long as the user of that library is updated in sync. (+6,0,0) 19:17:09 <mattdm> #topic #1244 F21 System Wide Change: cron to systemd time units 19:17:09 <mattdm> .fesco 1244 19:17:10 <Viking-Ice> Just so we are clear I don't intend migrating any cron jobs in any component that is not depend on the boot process one way or another to systemd timer units hence this list is limited strictly to packages that already depend on systemd which limits it to ca 40 out of 100 in total. 19:17:10 <zodbot> mattdm: #1244 (F21 System Wide Change: cron to systemd time units - https://fedoraproject.org/wiki/Changes/cron-to-systemd-time-units) – FESCo - https://fedorahosted.org/fesco/ticket/1244 19:17:10 <mattdm> https://fedoraproject.org/wiki/Changes/cron-to-systemd-time-units 19:17:18 <Viking-Ice> I personally think that's where we should draw the line when it comes down to timer units thus that's where my contribution ends. 19:17:42 <mattdm> Viking-Ice Yes, I think that's clear. 19:17:46 <mattdm> I'm +1 to this. 19:18:01 <mitr> I'm generally +1. 19:18:03 <pjones> sure, +1 19:18:14 <abadger1999> +1 19:18:30 <nirik> +1 19:18:32 <mitr> Historicaly, there were two areas of concern raised: 1) (vague) admin confusion, 2) interaction between enabling services and timer units (hasn't existed historically) 19:18:38 <mattdm> sgallagh is +1 in ticket with some requests for documentation changes 19:18:52 <mitr> Do we need to do anything about these? 19:19:19 <mattdm> mitr point to upstream docs in release notes. 19:19:55 <notting> given the list on the page, i would note that moving yum-cron to not use cron is a little weird from a naming standpoint. but that can be fixed. 19:19:58 <mattdm> Viking-Ice could you add that to the release notes section? 19:20:09 <mattdm> notting lol true 19:20:17 <t8m> I am +0 on this 19:20:21 <Viking-Ice> notting, yum-cron needs to be fixed to not use cron ( just look at what it does ) 19:20:36 <Viking-Ice> mattdm, reference to upstream docs sure 19:20:41 <mattdm> Viking-Ice thanks 19:20:48 <notting> Viking-Ice: oh, yes, it can. just saying that it perhaps should be renamed while doing so 19:20:50 <mattdm> notting are you voting? 19:20:57 <notting> mattdm: +1 19:21:09 <Viking-Ice> but I think we should be clear on only allowing components that already depend on the init process to be migrated 19:21:24 <mattdm> #agreed cron to systemd time units change accepted (+7,0,1) 19:21:36 <Viking-Ice> to timer unit otherwise we end up adding hard dependency on systemd for components that have nothing to do with the boot process 19:22:00 <mattdm> Viking-Ice I think that might be a FPC packaging policy thing. but as someone working on containers, I agree 19:22:22 <mattdm> Viking-Ice can we make that a separate discussion? lots to go through here still 19:22:33 <Viking-Ice> yeah sure carry on 19:22:34 <Viking-Ice> thanks 19:22:36 <Viking-Ice> later 19:22:42 <mattdm> #topic #1245 F21 System Wide Change: System-wide crypto policy 19:22:43 <mattdm> .fesco 1245 19:22:44 <zodbot> mattdm: #1245 (F21 System Wide Change: System-wide crypto policy - https://fedoraproject.org/wiki/Changes/CryptoPolicy) – FESCo - https://fedorahosted.org/fesco/ticket/1245 19:22:45 <mattdm> https://fedoraproject.org/wiki/Changes/CryptoPolicy 19:22:58 <abadger1999> This one seemed kinda iffy to me. 19:23:17 <notting> i like the idea of a system-wide policy. i kind of hate all the suggested policy levels. 19:23:18 <nirik> yeah, there were a number of concerns raised on list. 19:23:48 <nirik> yeah... 19:23:54 <abadger1999> Would it to be fair to say that it is a userspace implementation of a flexible fips mode? 19:24:12 <mitr> The policy levels are a bikesheding minefield... honestly the primary benefit is having an editable system-wide default. 19:24:37 <notting> abadger1999: not exactly. openssl has defaults, gnutls has defaults, etc. - the idea is to have a system default that those pull from 19:24:44 * nirik would personally just want "LOW" and "DEFAULT" 19:24:57 <mitr> abadger1999: Not really, this is much more TLS focused, and the expected uses are things like disabling RC4 and 3DES in TLS (which are rather different from the set of change you would need for FIPS) 19:25:06 <abadger1999> notting: okay. 19:25:14 <mitr> abadger1999: It's in that general area, yes. 19:25:49 <t8m> this is not really related to FIPS 19:25:51 <abadger1999> mitr: ah okay -- so it would be a way to disable those algorithms for use in tls globally... not to disable people from using those algorithms from those libraries? 19:25:52 * jreznik has to go, will process changes tomorrow morning, let him know in case of any issues raised 19:26:01 <mattdm> jreznik yep. 19:26:13 <t8m> abadger1999, yes, this affects TLS only 19:26:19 <abadger1999> k 19:26:22 <mitr> abadger1999: I'm not sure what's the difference... "globally" obviously depends on adoption in libraries and application's default configs. 19:26:31 <abadger1999> sounds less problematic than I was thinking then. 19:26:50 <mitr> abadger1999: There _is_ a general intent to expand this beyond TLS, but not for F21 19:27:09 <mattdm> since the "other developers" section is "should" rather than "must", I guess I am +1. 19:27:24 <mattdm> might as well try it and then if there is no uptake, oh well. 19:27:40 <mattdm> sgallagh is +1 in ticket 19:27:54 <mattdm> given the time, I'd like to either vote or defer 19:27:58 <t8m> +1 19:28:00 * nirik is 0 19:28:10 <abadger1999> mitr: k... when we get into the realm of preventing programs from making use of certain algorithms that they explicitly intend to I think we get into a tricky situation. 19:28:30 <notting> i am a +1, but strongly suggest rewriting the proposed security levels to something that does not require a t8m/sgrubb translator for the common sysadmin 19:28:47 <mitr> abadger1999: This is defaults only; applications still can adjust as they want (but generally shouldn't) 19:28:50 <abadger1999> <nod> 19:29:02 <mattdm> #info notting is +1, but strongly suggests rewriting the proposed security levels to something that does not require a t8m/sgrubb translator for the common sysadmin 19:29:05 <mitr> +1 19:29:18 <mattdm> pjones you still around? 19:29:20 <pjones> yeah. 19:29:32 <pjones> trying to figure out what I think still. 19:29:35 <abadger1999> +0.5 (since I'm not needed to pass) 19:29:39 <t8m> notting, btw I'd say that the concrete levels is an implementation detail that we should not discuss here 19:29:54 <pjones> (apologies, a bit behind this week.) 19:30:21 <mattdm> abadger1999 pick a rounding while pjones decides 19:30:24 <mitr> t8m: well... we kinda do need to write _something_ in the release notes, and if we didn't think those made sense, we might want to request a change. 19:30:26 <nirik> I suspect almost no one will change this. ;) 19:30:46 <pjones> I think I'm very, very weakly +1 19:30:50 <pjones> with the caveat. 19:31:15 <abadger1999> t8m: I think it's fair game but we can discuss that if the Change owner doesn't like the suggestion. 19:31:20 <mattdm> #agreed system-wide crypto policy change accepted (+6,0,0) 19:31:30 <abadger1999> mattdm: nirik voted 0 19:31:35 <mattdm> opps yes 19:31:37 <mattdm> #undo 19:31:37 <zodbot> Removing item from minutes: AGREED by mattdm at 19:31:20 : system-wide crypto policy change accepted (+6,0,0) 19:31:45 <mattdm> #agreed system-wide crypto policy change accepted (+6,0,1) 19:31:54 <mattdm> #topic #1246 F21 System Wide Change: Access control in PCSC 19:31:55 <mattdm> .fesco 1246 19:31:57 <mattdm> https://fedoraproject.org/wiki/Changes/PcscAccessControl 19:31:58 <zodbot> mattdm: #1246 (F21 System Wide Change: Access control in PCSC - https://fedoraproject.org/wiki/Changes/PcscAccessControl) – FESCo - https://fedorahosted.org/fesco/ticket/1246 19:32:17 <mitr> +1 19:32:19 <nirik> +1 19:32:50 <mattdm> +0; do not have or care about smartcards 19:32:50 <abadger1999> +1 19:33:14 <t8m> +1 19:33:26 <pjones> +1 19:33:38 <pjones> I have and care about smart cards, sadly, and I want this. 19:33:44 <notting> +1 19:33:57 <mattdm> #agreed access control in pcsc system-wide change accepted (+6,0,1) 19:34:09 <mattdm> #topic #1247 F21 System Wide Change: Remove python-setuptools-devel 19:34:11 <mattdm> .fesco 1247 19:34:12 <zodbot> mattdm: #1247 (F21 System Wide Change: Remove python-setuptools-devel - https://fedoraproject.org/wiki/Changes/Remove_Python-setuptools-devel) – FESCo - https://fedorahosted.org/fesco/ticket/1247 19:34:13 <mattdm> https://fedoraproject.org/wiki/Changes/Remove_Python-setuptools-devel 19:34:21 <mattdm> +1 rubber stamp 19:34:23 <mitr> +1 19:34:26 <pjones> +1 19:34:28 <abadger1999> +1 19:34:36 <notting> +1 19:34:40 <nirik> +1 19:34:44 <mattdm> sgallagh is +1 in ticket 19:35:12 <mattdm> #agreed remove python-setuptools-devel system-wide change is accepted (+7,0,0) 19:35:24 <mattdm> #topic #1248 F21 System Wide Change: Ruby 2.1 19:35:26 <mattdm> .fesco 1248 19:35:27 <zodbot> mattdm: #1248 (F21 System Wide Change: Ruby 2.1 - https://fedoraproject.org/wiki/Changes/Ruby_2.1) – FESCo - https://fedorahosted.org/fesco/ticket/1248 19:35:28 <mattdm> https://fedoraproject.org/wiki/Changes/Ruby_2.1 19:36:05 <notting> so this requires a mini-mass rebuild for ruby extensions? 19:36:10 <mattdm> +1 non-controversial change (Source level compatible) 19:36:13 <t8m> +1 19:36:21 <mattdm> notting yes. so there is that for the schedule 19:36:24 <mitr> +1 19:36:33 <mitr> notting: that is native extensions 19:36:45 <mattdm> #info this requires a mini-mass rebuild for native ruby extensions so schedule needs to account for that. 19:36:55 <mattdm> sgallagh is +1 in ticket 19:37:27 <nirik> +1 19:37:31 * pjones is +1 19:37:32 <notting> +1 19:37:42 <mattdm> #agreed ruby 2.1 system-wide change is accepted (+7,0,0) 19:37:50 <mattdm> #topic #1249 F21 System Wide Change: Lohit Odia Gurmukhi font naming 19:37:51 <mattdm> .fesco 1249 19:37:52 <zodbot> mattdm: #1249 (F21 System Wide Change: Lohit Odia Gurmukhi font naming - https://fedoraproject.org/wiki/Changes/Lohit_Odia_Gurmukhi) – FESCo - https://fedorahosted.org/fesco/ticket/1249 19:37:53 <mattdm> https://fedoraproject.org/wiki/Changes//Lohit_Odia_Gurmukhi 19:38:35 <mattdm> As I understand it, this is system-wide because it affects anaconda, and is primarily a communications channel 19:38:39 <mattdm> +1, then 19:38:43 <mitr> +1 19:38:46 <nirik> +1 19:38:52 <pjones> +1 19:38:56 <mattdm> sgallagh is +1 in ticket 19:38:57 <mitr> mattdm: I was expecting this to go the self-contained route, yes :) 19:39:09 <mitr> (please tell me if I'm being too pedantic about the categories) 19:39:20 <notting> +1 19:39:40 <mattdm> mitr I will not be pedantic about your pedantry :) 19:39:41 <abadger1999> +1 19:39:47 <abadger1999> (also a late +1 for the ruby update) 19:40:21 <mattdm> #agreed Lohit Odia Gurmukhi font naming system-wide change is accepted (+7,0,0) 19:40:30 <t8m> +1 for record 19:40:33 <mattdm> #undo 19:40:33 <zodbot> Removing item from minutes: AGREED by mattdm at 19:40:21 : Lohit Odia Gurmukhi font naming system-wide change is accepted (+7,0,0) 19:40:36 <mattdm> #agreed Lohit Odia Gurmukhi font naming system-wide change is accepted (+8,0,0) 19:40:44 <mattdm> okay that is all the system-wide ones 19:40:51 <mattdm> #topic #1250 F21 Self Contained Changes for week 11 19:40:53 <mattdm> .fesco 1250 19:40:54 <zodbot> mattdm: #1250 (F21 Self Contained Changes for week 11) – FESCo - https://fedorahosted.org/fesco/ticket/1250 19:40:55 <mattdm> #info Allwiner sunxi ARM SoC support 19:40:57 <mattdm> https://fedoraproject.org/wiki/Changes/AllwinnerSunxiSupport 19:40:59 <mattdm> #info OpenCL 19:41:01 <mattdm> https://fedoraproject.org/wiki/Changes/OpenCL 19:42:24 <mattdm> the opencl one seems to be an easy yes 19:43:11 <notting> really confused by adding support for a sun<blah> architecture back. but can be +1 to both. 19:43:32 <pjones> indeed. 19:43:33 <mattdm> there was some discussion on the list about the arm one 19:43:38 * pjones also +1 on both 19:43:43 <mitr> I suppose +1 "no escalations" is the way to proceed on this ticket 19:43:45 <nirik> are fedora kernel folks ok with it? 19:43:53 <nirik> otherwise +1 19:44:33 <mattdm> nirik jwb commented in the mailing list thread 19:44:44 <mattdm> and I *think* his comment was in favor 19:44:47 <nirik> ok, thought so, just couldn't recall for sure. 19:45:05 <mattdm> so yeah, I am +1 to both with no escalation 19:45:13 <mattdm> sgallagh was too 19:45:26 <jwb> erm 19:45:39 <mattdm> jwb was that right? That's why I mentioned you. :) 19:45:47 * abadger1999 waits for jwb to comment 19:45:52 <jwb> i commented in the thread that the original plan was to send whatever was needed shortly after 3.14-rc1 19:45:56 <jwb> we're now at 3.14-rc6 19:46:00 <jwb> i've not seen anything. 19:46:23 <jwb> nor am i aware if the rest of the ARM people are supportive of this or not 19:46:39 <mattdm> jwb that was the part I wasn't clear about -- wasn't sure where the holdup was 19:46:47 <jwb> yeah, i have no idea 19:46:55 <jwb> all that being said, since this is for f21 we can wait 19:47:14 <notting> jwb: feature filed by pbrobinson & hans - are there specific other arm people you're looking for info from? 19:47:22 <jwb> hans originally said most of the support should be in 3.15 and we're likely to use an even later version on f21 19:47:52 <pjones> so I think I'm not +1 any more and instead think we should just defer and ask them for comment 19:47:55 <jwb> notting, pbrobinson didn't really reply when i asked him directly about it. i know he's very busy but since this landed on the kernel list a while ago, there's been silence 19:48:05 <mattdm> okay, so, let's split these up. 19:48:34 <mattdm> proposal +1 to opencl, defer another week on allwinner arm 19:48:55 <mattdm> i can reword that :) 19:49:11 <notting> can do that too, +1 19:49:22 <nirik> +1, sure 19:49:34 <abadger1999> +1 19:49:35 <mattdm> reworded, same meaning: OpenCL self-contained change accepted. Defering another week on Allwinner arm while we wait for comments. 19:49:42 <mitr> This was properly announced, there were no concerns raised, and we don't have specific concerns but just would like an ack from sobebody else, without asking during the 9-day discussion window? 19:49:42 <t8m> +1 19:50:06 <mitr> I'm still +1 for both, I don't think deferring now is quite fair to the people porposing sunxi 19:50:09 <t8m> (+1 to both for the record) 19:50:14 <pjones> mattdm: +1 19:50:16 <jwb> mitr, i did ask during the discussion window 19:50:35 <pjones> mitr: there wasn't an /answer/ within the window 19:50:39 <jwb> or rather, i pointed out that the plan we agreed on hasn't actually been done 19:50:42 <pjones> (and still isn't, apparently.) 19:51:10 <jwb> i mean, if they want to rewrite it to say "use the 3.15 kernel" that's cool. i just have no idea what the actual status on this is 19:51:57 <mattdm> #agreed OpenCL self-contained change accepted. Deferring another week on Allwinner ARM for status update. (+5,-2,0) 19:52:12 <mattdm> as I count the votes and look at the clock :) 19:52:45 <mattdm> #topic Next week's chair 19:53:58 <mattdm> annnyone? 19:54:00 <nirik> I can if no one else can. 19:54:13 <mattdm> i think that's good as saying you will :) 19:54:19 <mattdm> #info nirik to chair next week 19:54:27 <mattdm> #topic Open Floor 19:54:27 <nirik> sure. 19:54:42 <nirik> I have one quick note re: mesa update.... 19:54:48 <mattdm> okay go 19:54:52 <nirik> from the qa channel a bit ago: "kerbal space program does not seem to even get to the loading screen if I update mesa from updates-testing 19:54:52 <nirik> " 19:55:01 <mattdm> ohhh noooooo! 19:55:09 <nirik> so, if we care, it does break non free stuff we don't ship 19:55:34 <abadger1999> heh. 19:55:41 * pjones tries to bring himself to give a damn 19:55:42 <nirik> just a FYI... 19:55:47 <abadger1999> That would be similar to the case that mitr was bringing up. 19:55:49 <pjones> nope, not happening. 19:56:19 <abadger1999> breaking of third party or local code. 19:56:24 <mattdm> I don't think it breaks minecraft or I would have heard about it 19:56:48 <drago01_> fwiw that has been in rawhide for months 19:56:56 <abadger1999> mattdm: hah! 19:57:17 <mitr> abadger1999: I was specifically talking about ABIs; though keeping the ABI and no longer working amounts to about the same thing 19:57:21 <nirik> drago01_: rawhide moved on to 10.1 a while back I thought? 19:57:47 <notting> nirik: how dos it fail? crash? missing symbol? just hangs? 19:58:01 <drago01_> nirik: Feb 08 19:58:02 <nirik> hangs apparently 19:58:39 <drago01_> nirik: and has been on 10.x since dec 01 19:58:47 <drago01_> nirik: so "for months" seems correct ;) 19:58:59 <nirik> ok. 19:59:12 <notting> nirik: *shrug*. that sounds like a bug, not necessarily an ABI issue 19:59:38 <nirik> same setup works fine with previous mesa packages... but anyhow, just wanted to note it since we were talking about that update. 20:00:21 <nirik> thats all, carry on. 20:00:30 <mattdm> yeah. i think mostly this goes back to it being nice for these things to take longer in updates-testing unless there is a really strong reason, and no autokarma 20:00:42 <mattdm> anything else for open floor? 20:01:10 <mattdm> I'll close the meeting in one minute.... 20:02:02 <mattdm> #endmeeting