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