=================================== #fedora-meeting: FESCO (2014-11-19) =================================== Meeting started by t8m at 18:08:14 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2014-11-19/fesco.2014-11-19-18.08.log.html . Meeting summary --------------- * init process (t8m, 18:08:27) * #1273 Policy interpretation on proprietary products in gnome-software, gnome overview search results (t8m, 18:11:53) * The web apps are clearly marked we can close the ticket (t8m, 18:13:49) * #1265 Fedora Plasma Product (t8m, 18:15:03) * Closing the ticket as the new product proposals should be presented to Fedora Council (t8m, 18:20:41) * #1326 change to fesco replacement process? (t8m, 18:21:37) * we will revisit this after F21 is released (t8m, 18:27:26) * #1359 Automatic OpenH264 download by Firefox (t8m, 18:28:36) * LINK: https://fedorahosted.org/fesco/ticket/1359#comment:26 looks like a possible long term solution (kalev, 18:30:24) * AGREED: Close the ticket and ask interested parties to work with legal on more user friendly solution (+7, -0, 0:0) (t8m, 18:47:07) * #1367 Please define package manager expectations (t8m, 18:48:27) * AGREED: post to devel list asking for interested parties to improve http://dnf.readthedocs.org/en/latest/cli_vs_yum.html and revisit change in the f22 cycle to see if there's any critical gaps (+6, -0, 0:0) (t8m, 19:07:09) * ACTION: nirik will post to the devel list (t8m, 19:08:20) * #1368 How to deal with F21 broken dependencies (t8m, 19:08:56) * AGREED: FESCo agrees to dropping the packages with broken dependencies listed in #1368 from both F21 and rawhide (+7, -0, 0:0) (t8m, 19:25:56) * AGREED: We will do the broken deps cleanup on Final Freeze from now on in the future Fedora releases (+8, -0, 0:0) (t8m, 19:30:41) * There will be warning sent to the affected maintainers at least 3 weeks in advance (t8m, 19:31:36) * #1369 packages should disable internal crash handlers and depend on ABRT (t8m, 19:32:44) * Decision postponed to next week (t8m, 19:57:36) * Next week chair (t8m, 19:57:40) * ACTION: nirik will chair the next week meeting (t8m, 19:59:10) * Open floor (t8m, 19:59:18) Meeting ended at 20:01:44 UTC. Action Items ------------ * nirik will post to the devel list * nirik will chair the next week meeting Action Items, by person ----------------------- * nirik * nirik will post to the devel list * nirik will chair the next week meeting * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * t8m (100) * nirik (73) * mitr (58) * kalev (50) * dgilmore (33) * thozza (32) * mattdm (31) * jwb (31) * sgallagh (27) * zodbot (15) * randomuser (13) * cschalle_ (13) * sharkcz (12) * jzeleny (8) * oddshocks (4) * kushal (3) * scollier (2) * mjg59 (1) * mmaslano (0) * stickster (0) ------- 18:08:14 <t8m> #startmeeting FESCO (2014-11-19) 18:08:15 <zodbot> Meeting started Wed Nov 19 18:08:14 2014 UTC. The chair is t8m. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:08:15 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:08:19 <t8m> #meetingname fesco 18:08:19 <zodbot> The meeting name has been set to 'fesco' 18:08:22 <t8m> #chair dgilmore jwb kalev mattdm mitr mmaslano nirik sgallagh stickster t8m thozza 18:08:23 <zodbot> Current chairs: dgilmore jwb kalev mattdm mitr mmaslano nirik sgallagh stickster t8m thozza 18:08:27 <t8m> #topic init process 18:08:27 <nirik> .hello kevin 18:08:28 <zodbot> nirik: kevin 'Kevin Fenzi' <kevin@xxxxxxxxx> 18:08:31 <sgallagh> .hello sgallagh 18:08:32 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@xxxxxxxxxx> 18:08:38 <t8m> Hi all I apologize again 18:09:00 <thozza> .hello thozza 18:09:01 <zodbot> thozza: thozza 'Tomas Hozza' <thozza@xxxxxxxxxx> 18:09:04 <mattdm> t8m we'll just have to talk fast to make up for it :) 18:09:07 * mattdm is here 18:09:16 <dgilmore> hi 18:09:33 <jwb> hi 18:09:34 <sgallagh> mattdm: lts jst skp vwls fr spd 18:10:37 <kalev> hi 18:11:30 <t8m> OK, so let's finally start 18:11:53 <t8m> #topic #1273 Policy interpretation on proprietary products in gnome-software, gnome overview search results 18:12:04 <t8m> .fesco 1273 18:12:09 <zodbot> t8m: #1273 (Policy interpretation on proprietary products in gnome-software, gnome overview search results) – FESCo - https://fedorahosted.org/fesco/ticket/1273 18:13:07 <nirik> I think this is done and can be closed. 18:13:08 <t8m> So it seems we can close this ticket because the marking of Web apps was accepted upstream and is in Fedora if I understand this correctly 18:13:16 <nirik> the "apps" are marked pretty clearly now. 18:13:21 <mattdm> yeah, exactly. 18:13:26 <t8m> OK 18:13:35 <mattdm> there are some other issues but I don't think they are fesco issues 18:13:49 <t8m> #info The web apps are clearly marked we can close the ticket 18:13:53 <t8m> next topic 18:13:55 <randomuser> I'm generally in agreement, but I don't like the concept of 'this was accepted upstream therefore we are okay with it' 18:14:11 <randomuser> ...just an observation, carry on 18:14:18 <t8m> randomuser, I think it is in Fedora already, isn't it? 18:14:31 <kalev> I think it's more like "what we wanted was accepted upstream so we can move on" 18:14:34 <mitr> randomuser: No, this is “Board decision caused us to file an upstream ticket and upstream resolved it as requested so we can close our tracking ticket“ 18:14:35 <nirik> randomuser: well, it was accepted upstream after we worked with them on wording that we find acceptable? 18:14:42 <mattdm> randomuser: I think the other issues there are non-fesco -- they are for the WG and possibly for the council (as part of the same discussion as firefox ads) 18:15:03 <t8m> #topic #1265 Fedora Plasma Product 18:15:12 <t8m> .fesco 1265 18:15:13 <zodbot> t8m: #1265 (Fedora Plasma Product) – FESCo - https://fedorahosted.org/fesco/ticket/1265 18:15:13 <randomuser> phrased as kalev has, no complaints :) 18:15:43 <t8m> So this again can be closed? 18:16:03 <nirik> I think this one went to the board, but the resolution wasn't clear (if it has been resolved?) 18:16:52 <sgallagh> nirik: Last I heard, the Board kind of petered out trying to solve the wider question of how a Product is promoted from a Spin 18:17:06 <sgallagh> But I *think* they rejected the proposal as it currently stood 18:17:14 <sgallagh> jwb: Am I remembering that right? 18:17:17 <t8m> jwb seems to have different opinion? 18:17:20 <t8m> in the ticket 18:17:33 <mitr> I don’t think anybody has actually decided whether the Plasma proposal “addresses a new, relevant, ..” etc. and just fulfills the decided criteria. 18:17:38 <nirik> right, so I would be ok leaving this around, or closing it... until we hear from the board/council that we should address technical stuff around a new product? 18:17:48 <jwb> it's the opposite 18:18:08 <jwb> the board approved generic criteria for new products, but didn't explicitly weigh in on kde plasma 18:18:16 <jwb> either way, nothing for fesco to do here 18:18:48 <kalev> I'd say close the ticket and reopen if the board decides to move forward with the plasma product 18:18:49 <sgallagh> jwb: I'm glad I asked, then :) 18:19:03 <t8m> who will decide whether particular new product proposal conforms to the criteria? 18:19:32 <jwb> t8m, the Council 18:19:42 <nirik> fair enough 18:19:45 <t8m> jwb, ok, then we should close this ticket 18:20:10 <dgilmore> t8m: agreed 18:20:18 <thozza> t8m: +1 18:20:23 <mitr> t8m: … asking the KDE SIG to open a new Council ticket if they still/again want to pursue this? 18:20:23 <nirik> +1 18:20:34 <jwb> they talked about it yesterday in their meeting 18:20:34 <mitr> t8m: +1 18:20:38 <kalev> t8m: +1 18:20:41 <t8m> #info Closing the ticket as the new product proposals should be presented to Fedora Council 18:20:57 <mattdm> +1 18:21:01 <t8m> I do not think we need a formal vote for this 18:21:11 <sgallagh> I agree 18:21:12 <mattdm> also that :) 18:21:18 <t8m> next topic 18:21:37 <t8m> #topic #1326 change to fesco replacement process? 18:21:43 <t8m> .fesco 1326 18:21:45 <zodbot> t8m: #1326 (change to fesco replacement process?) – FESCo - https://fedorahosted.org/fesco/ticket/1326 18:22:31 <t8m> Is there any proposal? 18:22:39 <mattdm> sgallagh? 18:22:42 <t8m> If not, do we want to keep this ticket open? 18:22:48 <sgallagh> I haven't written one yet. 18:23:00 <sgallagh> I do think we need to solve this, but it's been low on the priority list lately 18:23:26 <mattdm> after f21 ships, say 18:23:30 <t8m> I understand that with the F21 release 18:23:53 <thozza> and before next elections? 18:24:20 <sgallagh> /me nods 18:24:32 <t8m> hmm, when the next elections come? Shouldn't they be just after F21 release? 18:25:11 <nirik> t8m: with f21 in december, I would think they would be in january... 18:25:28 <nirik> because there's not much way to do things over the holidays... people won't be around, people won't vote, etc. 18:25:33 <t8m> ok 18:25:45 <t8m> so hopefully there is some time to work on this in between 18:26:00 <nirik> but this ticket is also about filling empty seats right? or revamping the entire process? 18:26:43 <sgallagh> nirik: It's also about having some form of recall capability (IMHO) 18:27:02 <jwb> then maybe we should fix the ticket subject 18:27:05 <nirik> which I think is mixing two issues. 18:27:15 <dgilmore> sgallagh: recall is a horrible idea 18:27:16 <nirik> or multiple issues. 18:27:26 <t8m> #info we will revisit this after F21 is released 18:27:32 <mitr> sgallagh: https://fedorahosted.org/fesco/ticket/1326#comment:9 ? 18:27:38 <dgilmore> sgallagh: and as mattdm said in the ticket file a seperate ticket for it 18:28:11 <t8m> moving on? 18:28:17 <dgilmore> yes 18:28:36 <t8m> #topic #1359 Automatic OpenH264 download by Firefox 18:28:59 <nirik> I think this is mostly all done. 18:29:17 <thozza> IIRC kalev wanted to discuss something today, right? 18:29:19 <nirik> oh, but there was possibly some more stuff this week from cschalle_ ? 18:29:41 <t8m> .fesco 1359 18:29:43 <zodbot> t8m: #1359 (Automatic OpenH264 download by Firefox) – FESCo - https://fedorahosted.org/fesco/ticket/1359 18:29:46 <nirik> I've drafted a rough wiki page for manually installing the plugin, and asked legal to look it over. 18:30:24 <kalev> https://fedorahosted.org/fesco/ticket/1359#comment:26 looks like a possible long term solution 18:30:31 <kalev> I think the plan makes sense 18:30:57 <jwb> i would if it were feasible 18:31:03 <jwb> but it doesn't seem possible with koji 18:32:02 <kalev> it should be possible for a third party to do a scratch build in koji and then download the rpm and sign with their own keys 18:32:08 <dgilmore> jwb: its possible 18:32:17 <jwb> except that means that anyone can download it from koji 18:32:25 <jwb> which runs afoul of the licensing aspects 18:32:39 <jwb> because if anyone can download it from koji, we could just build it ourselves in the first place 18:32:55 <mitr> jwb: Not being a lawyer, that last conclusion is not at all obvious to me. 18:33:10 <sgallagh> And if they can't download it from Koji, there's no way to verify it's the same package 18:33:24 <dgilmore> jwb: we can, but then there is no patent grant 18:33:26 <nirik> perhaps we could make them a packager and they can build it as normal for a fedora package, but we just never ship it, they do? 18:33:28 <kalev> I think the issue here is that Cisco says that they have 18:33:29 <mitr> sgallagh: We could sign it with a Fedora-built-this-for-the-Cisco-user key 18:33:32 <jwb> mitr, we cannot build the code and distribute it ourselves because Cisco paid the patent fees 18:33:38 <sgallagh> mitr: OK, valid point 18:33:38 <jwb> dgilmore, which makes it pointless 18:33:39 <cschalle_> jwb, no, the fact that people can get and build the sourcecode elsewhere is not relevant to the issue of coverage by Cisco's patent license 18:33:40 <dgilmore> jwb: i say we leave that to the lawyers 18:33:47 <kalev> I think the issue here is that Cisco says that they are only providing the patent coverage if they distribute the codec 18:34:02 <kalev> we can download the code and built it ourselves, except that we won't be covered then 18:34:10 <jwb> right, which makes it pointless 18:34:11 <sgallagh> kalev: I'm not sure if it's "are only" or "can only" 18:34:24 <cschalle_> jwb, the only thing that matters is that the binary comes from Cisco 18:34:35 <dgilmore> jwb: thats for the lawyers to decide not us 18:34:38 <cschalle_> jwb, why pointless? 18:34:49 <jwb> cschalle_, yes, but my point is that anyone can download it from koji, which makes fedora the distributor 18:34:56 <jwb> which means no patent grant 18:35:20 <nirik> jwb: only if someone does that... why would they? 18:35:20 <t8m> jwb, +1 18:35:21 <cschalle_> jwb, yes, but why does it matter if people can get a non-licensed binary from koji or anywhere lese 18:35:48 <cschalle_> I mean what does maybe matter is that 'we' are offering that binary, so we might need to find a way to block it 18:35:51 <mjg59> cschalle_: Patents cover distribution as well as use 18:35:57 <thozza> could we encrypt it for Cisco? 18:36:03 <kalev> does it make Red Hat legally liable somehow if it comes from koji.fedoraproject.org ? 18:36:04 <nirik> IMHO, it would be ideal if they had packager access to that package and built it like any other, and then they distribute it... 18:36:07 <thozza> so no one can use it? 18:36:07 <jwb> cschalle_, yes, exactly. koji doesn't block 18:36:14 <t8m> cschalle_, because then we could be liable for patent violation 18:36:15 <randomuser> cschalle_, what's the benefit of cisco using our koji, instead of, say, mock 18:36:24 <cschalle_> jwb, but I am sure that is a smaller issue we can fix somehow 18:36:33 <mitr> randomuser: We have a proof of correspondence between the binary and the source 18:36:33 <cschalle_> randomuser, they don't have to host anything themselves 18:36:35 <nirik> there's no violation.... it's a grant or not. 18:36:38 <jwb> cschalle_, if we could, then we'd be able to do real security builds too 18:36:41 <dgilmore> jwb: again leave it to the lawyers to figure out 18:36:54 <t8m> dgilmore, +1 18:37:03 <jwb> i mean, i'm all for this but without having a way for koji to prevent access to a class of builds it seems very very tenuous at best 18:37:17 <nirik> if the rpm built in our koji from source they uploaded is the same as the one they distribute... thats a good thing. 18:37:22 <kalev> I think we can ask for a koji feature if it's needed? 18:37:26 <mitr> jwb: Yes. Do we need to, and can we even, get this negotiated here and now? 18:37:37 * nirik doesn't understand why we need to prevent anything 18:37:45 <randomuser> cschalle_, are they resistant to providing resources to run mock, or just resources to distribute it? 18:37:48 <t8m> So what shall we do with the ticket? Close for now? 18:37:58 <jwb> mitr, negotiate what? 18:38:09 <cschalle_> randomuser, the first 18:38:15 <mitr> jwb: What is legal/desirable/riskless enough/technically possible/has allocated manpower/gets done 18:38:26 <dgilmore> it will all come down to the legal agreements 18:38:28 <randomuser> cschalle_, well, that's absurd, then. The tooling isn't that much of a burden. 18:38:58 <sgallagh> nirik: We *are* legally liable if someone can download the binaries from our servers. We are then distributing it. (At least, that's my non-legal-expert opinion) 18:38:59 <dgilmore> so riight now we have a page to document how to get the bits 18:39:00 <nirik> randomuser: they want to be distributing the binary, because they have the patent grant. They want to know it's from the source they have. 18:39:01 <mitr> t8m: Having someone take the action to write the manual installation instruction would be useful; then I guess we can either close it and have cschalle_ and Fedora legal and all the various other parties agree on a solution, or keep tracking it in this ticket. 18:39:11 <cschalle_> nirik, the reason we need to block is because Fedora/RH could be liable for patent infringement if we ship a h264 binary from our website 18:39:13 <dgilmore> we have ff not auto downloading 18:39:35 <nirik> mitr: as I noted, I have already done that and asked legal to vet them. 18:39:41 <dgilmore> what do we need to discuss for the ticket? or can we close it? 18:39:43 <thozza> t8m: I'm for closing it.... Open new ticket if needed 18:39:53 <t8m> thozza, I agree 18:39:55 <mitr> nirik: Right, sorry. 18:40:00 <thozza> we will not solve it here today 18:40:10 * kalev agrees. 18:40:17 <nirik> bah, yeah, so I'd say cschalle_ / spot / cisco try and work out some scheme and bring it back to us to approve? 18:40:25 <t8m> nirik, +1 18:40:29 <jwb> cschalle_, i'd suggest getting ahold of the koji developers to see if they can provide blocked access sooner rather than later 18:40:31 <cschalle_> as a sidenote I also asked RH product management to verify that we are not in breach of our contract with Mozilla Copr. by disabling the h264 feature 18:40:36 <thozza> nirik: and to the legal first 18:40:50 <cschalle_> jwb, ok, will add it to my todo 18:41:15 <jwb> cschalle_, ok. feel free to CC me if you'd like. this kind of hinges on that in my opinion. plus, it would allow other things as well 18:41:44 <cschalle_> s/Copr/Corp/ 18:41:45 <mitr> nirik: Perhaps add infra to the list, then s/to approve/to inform us/ because I’m not sure what could be a blocker. 18:41:46 <dgilmore> cschalle_: our legal agreement with cisco may make it okay. 18:42:24 <mitr> nirik: Not sure whether committing not to be a roadblock would make the negotiations easier or whether we need to sanity-check more than that. 18:42:32 <cschalle_> dgilmore, yeah, I just know that is has been an issue in the past if we add things to FF that is not in the upstream project, so I am wondering if they same is true for removing stuff 18:42:35 <dgilmore> cschalle_: it all depends on the lawyers and here is the wrong place to speculate 18:43:03 * nirik is not a fan of the idea of 'non downloadable' stuff in koji... but I guess we see what everyone can come up with here. 18:43:36 <sgallagh> nirik: Well, perhaps "built with an ACL for limited access"? 18:43:39 <jwb> nirik, 'restricted access' 18:43:51 <jwb> again, it could have other benefits as well 18:43:52 <sgallagh> This *would* make testing security fixes easier too... 18:44:00 <nirik> I guess. still not a fan. Default to open. ;) 18:44:16 <mattdm> nirik: yeah but we have a big disadvantage for embargoed updates 18:44:36 <nirik> thats another can o worms. ;) 18:44:39 <mattdm> anyway cschalle_ please keep Fedora Legal in the loop here 18:44:56 <dgilmore> mattdm: yes but thats much more than just koji to change 18:45:12 <nirik> yes, tons of work for that 18:45:41 <jwb> some things are worth working for 18:45:51 <t8m> #proposal Close the ticket and ask interested parties to work with legal on more user friendly solution 18:46:03 <dgilmore> +1 18:46:09 <thozza> t8m: +1 I thought we already kind of agreed on that 18:46:10 <nirik> +1 18:46:16 <sgallagh> +1 18:46:18 <kalev> +1 18:46:24 <t8m> thozza, the discussion continued 18:46:33 <mattdm> +1 18:46:43 <thozza> but out of the scope of the original ticket 18:47:07 <t8m> #agreed Close the ticket and ask interested parties to work with legal on more user friendly solution (+7, -0, 0:0) 18:47:14 <t8m> moving on 18:47:27 <thozza> t8m: the discussion would continue if you would not propose the proposal ;) 18:48:27 <t8m> #topic #1367 Please define package manager expectations 18:49:08 <t8m> .fesco 1367 18:49:10 <zodbot> t8m: #1367 (Please define package manager expectations) – FESCo - https://fedorahosted.org/fesco/ticket/1367 18:49:20 <randomuser> I want to make it clear that this is an appeal to expertise, not authority. I'm not trying to go over the DNF maintainer's heads to FESCO - it just occurred to me that the discussion should happen and I brought the idea to people I thought qualified to do it 18:51:17 <t8m> I am not sure FESCo can come with concrete proposal that would completely define this. We can decide on particular problems probably but define the complete expectations from the package management tool. 18:51:26 <nirik> so, we have already approved the dnf change right? so this is more about documenting differences and/or things we really would like to fix before that change 18:51:50 <t8m> nirik, I could see morphing the ticket this way :) 18:52:26 * randomuser is fine with that view of the ticket - the goal is no last minute complaints or surprises 18:52:46 <nirik> I'm not sure how to really gather that though... as things have come up over time and from various people. 18:52:49 <mitr> I guess my general expectation was for dnf to be as close to a non-breaking drop-in replacement as possible (see also the older discussions about the /usr/bin/yum name), accepting some unavoidable exceptions. I’ve been reasonably impressed with some of the earlier-written documentation of yum/dnf differences maintained by the dnf team, and if they continue to keep such documentation of things they encounter (either personally or through 18:52:51 <mitr> bug reports) then I think we’re vely likely to end up with a solid improvement and a reasonable migration path. 18:53:31 <mitr> (specifically http://dnf.readthedocs.org/en/latest/cli_vs_yum.html ) 18:53:59 <mattdm> mitr: that's my expectation too. 18:54:12 <mattdm> however, I think some of those thigns have a bigger impact than the developers anticipated 18:54:12 <t8m> mitr, +1 18:54:29 <dgilmore> randomuser: there is likely to always be last minute changes 18:54:40 <mattdm> and I really want minimization of change cost to users to be a guiding principle 18:54:46 <dgilmore> and possibly changes after switching 18:55:03 <randomuser> dgilmore, that's not a reason to avoid being proactive in smoothing the transition 18:55:21 <mattdm> the ticket notes that the change proposal sets compatibility expectations and has been accepted 18:55:21 <dgilmore> as new corner cases are discovered or additional missing functionality is discovered 18:55:22 <t8m> mattdm, I agree although I think there is still some place for these rough edges to be fixed during the F22 development 18:55:34 <mattdm> but in actuality, what it does is point to the documentation, which is not static 18:55:36 <nirik> That doc is a good start... I guess we could ask people to add to it? and/or if someone wants to look through old dnf bugs for any that were missed? 18:55:40 <mitr> Yeah, a last-minute (pre-Beta) sanity check of the difference list might be worthwhile. But so far I think we can trust the dnf project to maintain that page, and it is both better and easier-to-maintain starting point than a list of FESCo-requested functionality. 18:56:26 <mitr> nirik: Asking for more help making sure that list is accurate and comprehensive can’t hurt. 18:56:43 <dgilmore> randomuser: sure, but thats not your stated goal 18:58:02 <mattdm> t8m: I'm happy with that -- I just don't want f22 to be handing those rough edges to our users 18:58:14 <t8m> mattdm, I completely agree 18:58:21 <randomuser> dgilmore, I guess I'm thinking of it more as a general concern with an implementation suggestion, rather than a take-it-or-leave-it proposal 18:59:28 <mattdm> offhand, there are several of the documented differences which seem very likely to be problematic to me 18:59:43 <jzeleny> mattdm: just for the record, yum will still be fully functional in F22 so users that will have problems with any functionality will always have the option to keep using it while we address their use cases 18:59:43 <mattdm> (Not sure this meeting is the place to go through them, though) 19:00:08 <nirik> proposal: post to devel list asking for interested parties to improve http://dnf.readthedocs.org/en/latest/cli_vs_yum.html and revisit change in the f22 cycle to see if there's any critical gaps. 19:00:20 <dgilmore> nirik: +1 19:00:23 <mitr> jzeleny: http://fedoraproject.org/wiki/Changes/ReplaceYumWithDNF says dnf-yum will be installed. 19:00:25 <sgallagh> nirik: +1 19:00:30 <mattdm> jzeleny: But "dnf is frustrating, just install yum" is not a good outcome. if it's not ready we shouldn't ship it 19:00:33 <t8m> nirik, +1 19:00:50 <jzeleny> mitr, yes but you can always replace it with yum 19:00:51 <thozza> nirik: +1 19:00:52 <nirik> but hopefully we can identify any problems well in advance to give dnf folks time to fix them... 19:01:02 <mitr> jzeleny: o..k.. 19:01:35 <jzeleny> mattdm: agreed, I hope those cases will be reduced way below 1% 19:01:43 <mitr> nirik: +1. We want many eyeballs on this (but also the freedom to say “no” in specific cases) 19:03:02 <mattdm> jzeleny: that seems like a great goal to me. can we do something to get some more-objective measurements of the impact of some of these changes? 19:03:45 <randomuser> It would be nice to have fesco weigh in on specific cases, however informally - we all will probably have opinions, but to a point most will be expressing impact on themselves, not a broader view 19:04:07 <jzeleny> mattdm: no idea, if there are any suggestions, I welcome them 19:04:11 <jzeleny> randomuser: exactly 19:04:24 <mitr> randomuser: I think it is fair to expect FESCo to be involved in the mailing list discussion. As for a broader point of view, we can hope ☺ 19:04:27 <kushal> Btw, after FESCO meeting is over, we (fedora cloud) want to stat our meeting. 19:04:27 <mattdm> So, I guess also on the documentation/expectations concern -- it would be nice to have the change page updated or a ping to fesco if the cli_vs_yum page changes significantly 19:05:03 <kalev> I'll note that in practice, we've been shipping dnf and yum in parallel for 2 releases, both in F20 and F21 19:05:16 <mitr> mattdm: I’m not sure we want to have dnf on agenda every month :) 19:05:24 <kalev> the reason for this is that anaconda pulls dnf in to the live images so it just is there, always 19:05:28 <jzeleny> mattdm: we keep the page up to date 19:05:35 <kalev> and due to that, it's gotten quite a bit of testing already 19:05:38 <randomuser> jzeleny, we can also work out some Fedora Guide to DNF or similar if it would help 19:05:40 <jzeleny> mattdm: any time we encounter something that is not documented there, we add it 19:05:41 <mitr> mattdm: … ah, “significantly”; I take that back. 19:05:42 <mattdm> jzeleny In the absence of data, I think it makes the most sense to consider any change from the yum semantics as "very painful", and bend over backwards (via default plugins or whatever) to make the behavior as similar as posislbe. 19:05:49 <kalev> if it turns out we're not confident in dnf in F22, we can continue shipping yum as well 19:06:04 <mattdm> jzeleny: but fesco doesn't notice automatically 19:06:14 <t8m> so nirik are you +1 to your own proposal? 19:06:16 <kalev> kushal: you guys could try #fedora-meeting-1 or #fedora-meeting-2 19:06:18 <jzeleny> randomuser: not sure. I was hoping the dnf documentation can take that role 19:06:21 <nirik> kushal: sorry, we moved for DST, and I guess you didn't? 19:06:23 * scollier here 19:06:31 <nirik> t8m: yep 19:06:42 <randomuser> jzeleny, ack - just an idea 19:06:57 <mattdm> I'm *really* not trying to be difficult or antagonistic her.e 19:07:09 <t8m> #agreed post to devel list asking for interested parties to improve http://dnf.readthedocs.org/en/latest/cli_vs_yum.html and revisit change in the f22 cycle to see if there's any critical gaps (+6, -0, 0:0) 19:07:22 <kushal> Okay 19:07:23 <mattdm> I feel like 90% of the systemd pain could have been avoided with greater attention to some of these details. 19:07:26 <t8m> nirik, will you take that action yourself? 19:07:26 * oddshocks pops in a few moments late 19:07:38 * oddshocks forgot to snooze his reminder, instead dismissed it 19:07:52 <mattdm> oddshocks scollier -- we're still runnikng over with the fesco meeting 19:07:54 <jwb> CLOUD GUYS: FESCo meeting in here right now 19:07:55 <nirik> t8m: sure, I can 19:07:58 <oddshocks> oh hehe I see that now 19:08:01 <oddshocks> my bad 19:08:02 <mitr> mattdm: … Let’s not go there? 19:08:06 <scollier> mattdm, ok 19:08:20 <t8m> #action nirik will post to the devel list 19:08:26 <kalev> CLOUD GUYS: can you guys to #fedora-meeting-1 or #fedora-meeting-2, looks like fesco is going on for a bit more? 19:08:39 <thozza> let's move on 19:08:56 <t8m> #topic #1368 How to deal with F21 broken dependencies 19:09:00 <nirik> another reason DST is anoying... if all meetings don't move to it, you get overlaps. ;( 19:09:01 <t8m> .fesco 1368 19:09:02 <zodbot> t8m: #1368 (How to deal with F21 broken dependencies) – FESCo - https://fedorahosted.org/fesco/ticket/1368 19:09:26 <mattdm> mitr I don't mean it in a "systemd sucks" way. I mean it in a "systemd is great, but was badly received and that still reverberates" way -- let's avoid doing it again 19:09:28 <nirik> kalev: can you provide an updated list now? 19:09:29 <kushal> nirik, Yup, we stayed with UTC :) 19:09:44 <mitr> mattdm: I would turn this into a systemd griping session and I’d rather not :) 19:09:51 <kalev> nirik: sure, hold on 19:09:53 <nirik> yes, lets move on please. 19:09:56 <t8m> mitr, +1 :) 19:10:00 <mattdm> mitr: yes don't want to go there. moving on :) 19:10:28 <t8m> So do we agree with the plan blocking the broken deps packages from F21? 19:10:53 <mitr> This seems not controversial. Two questions though: 1) Should this be a regular action (on the schedule), and 2) So are the packages orphaned or the maintainers unresponsive? Usually we go unresponsive maintainer → orphaned → retired, and this skips straight to the end. 19:10:59 <t8m> and from rawhide? 19:11:40 <dgilmore> t8m: f21 is frozen, we do allow package removal up until RC1 comes in, so the window is tiny 19:12:02 <thozza> t8m: I don't think we should remove things from rawhide 19:12:29 <t8m> thozza, yep, I agree that for rawhide the nonresponsive packager process should be followed 19:12:30 <dgilmore> t8m: the way things work it removes from rawhide also 19:12:44 <thozza> hmm 19:12:54 <t8m> dgilmore, is that the only way? 19:13:06 <kalev> nirik: the ticket should be up to date -- except that we have one new broken dependency, which is gearbox 19:13:20 <t8m> mitr, we previously dropped ftbfs packages only 19:13:23 <dgilmore> t8m: with extra work we could leave them in rawhide 19:13:35 <mitr> t8m: http://fedoraproject.org/wiki/Retire_Orphaned_Packages 19:13:47 <dgilmore> kalev: gearbox is being fixed 19:13:47 <kalev> I would argue that keeping them in rawhide just makes rawhide more broken and less pleasant to use 19:14:20 <kalev> dgilmore: we're frozen though, so the gearbox update can't go to stable -- any ideas what to do with that? 19:14:21 <t8m> kalev, dropping them just now without proper prior warning from rawhide seems to me bad 19:14:29 <mitr> kalev: I’d rather not retire something for a possibly temporary problem. That seems unnecessarily harsh. 19:14:32 <dgilmore> kalev: it can 19:14:35 <thozza> i think we should try to improve rawhide by some taskotron job checking broken dependencies rather than removing packages 19:14:40 * mattdm temporarily afk be right back 19:14:48 <mitr> kalev: As long as it is in none of the default comps groups, a zero-day update would fix everything, wouldn’t it? 19:14:52 <dgilmore> kalev: can be proposed and accepted as nth 19:15:11 <mitr> thozza: … and then what if taskotron reports a failure? 19:15:12 <dgilmore> well freeze exception 19:15:19 <nirik> most of these have been broken for a long while. 19:15:22 <kalev> dgilmore: sounds good, I'll file a freeze exception for this 19:15:29 <nirik> maintainers get an email every single day about them. 19:15:31 <thozza> mitr: don't push it into the rawhide repo 19:15:37 <kalev> yes, most of these have been broken for months, with no action being taken 19:15:43 <thozza> and notify the maintainer 19:15:52 <kalev> and with daily notifications going out to maintainers that they are broken 19:15:59 <mitr> nirik, kalev: So what about the packages? Do we mass-initiate an unresponsive maintainer procedure? Orphan them immediately without? 19:16:25 <nirik> I'd be in favor of orphaning and blocking them in both f21 and rawhide... 19:16:28 <kalev> I would make this a regular thing to do before each Fedora release 19:16:39 <nirik> and yeah, it seems a good thing to do before every release. 19:16:40 <jwb> nirik, yes 19:16:41 <mitr> Keeping “maintained” and “owned” packages that actually aren’t in the repo is strange. 19:16:44 <kalev> one week before the release, anything that has broken deps gets dropped from both the Branched and Rawhide releases 19:16:59 <nirik> they would then be retired in 2 weeks if no one claims them. 19:17:01 <thozza> kalev: I see your point with the reminders... I think it is obvious nobody cares 19:17:12 <sgallagh> kalev: I'd switch that to "at Final Freeze", but I agree with the sentiment 19:17:47 <kalev> sgallagh: sure, it can be _both_ -- would be good to have another check before the freeze to deal with anything that might have gotten broken in the mean time 19:17:55 <nirik> the nice thing then would be the base everything repo which is frozen for all time wouldn't have broken deps. 19:19:38 <dgilmore> nirik: indeed 19:20:27 <t8m> do we have any concrete proposal to vote on? 19:21:04 * nirik can write one up, or kalev you have one? 19:21:13 <kalev> I can write one too 19:22:14 <kalev> proposal: FESCo agrees to dropping the packages with broken dependencies listed in #1368 from both F21 and rawhide 19:22:29 <kalev> proposal: #action Kalev to file a releng ticket for the retirement 19:22:37 <thozza> kalev: +1 19:22:45 <mitr> kalev: +1 19:22:49 <kalev> kalev: +1 19:23:03 <jwb> +1 19:23:04 <t8m> what if the package has broken deps only in F21 and not in rawhide? 19:23:05 <nirik> +1 (and to clarify that means blocking and orphaning riight? 19:23:24 <kalev> that was my intention at least 19:23:38 <dgilmore> +1 19:23:47 <mitr> kalev: Were the package maintainers Cc:ed/separately contanced beyond the automated broken deps reports? 19:24:00 <kalev> mitr: yes, I added a huge CC list last week 19:24:05 <thozza> t8m: good point 19:24:24 <mitr> t8m: Is there such a package? 19:24:33 <t8m> mitr, I don't know actually 19:24:50 <nirik> if there is, Id be fine leaving it alone in rawhide. ;) 19:25:03 <kalev> I'll double check, but I believe they are all broken in both 19:25:10 * nirik thinks they are too 19:25:19 <t8m> OK, +1 then 19:25:31 <kalev> do we want to make this a regular event? 19:25:56 <t8m> #agreed FESCo agrees to dropping the packages with broken dependencies listed in #1368 from both F21 and rawhide (+7, -0, 0:0) 19:26:05 <mitr> kalev: Yes, this should be an item on the schedule. 19:26:08 <sgallagh> late +1, sorry 19:26:10 <nirik> kalev: +1 to adding it to the normal schedule 19:26:27 <sgallagh> Yes, I think this should happen at Final Freeze from here forwards 19:26:56 <mitr> sgallagh: i.e. first warning ~2 weeks in advance? 19:27:12 <sgallagh> mitr: Yes 19:27:19 <t8m> #proposal We will do the broken deps cleanup on Final Freeze from now on in the future Fedora releases 19:27:26 <sgallagh> Or perhaps, "first warning at Beta release"? 19:28:01 <nirik> a few weeks in advance would be fine I would think... as a reminder to get in gear. ;) 19:28:01 <mitr> Anything longer than 2 weeks works just as well for me 19:29:04 <dgilmore> t8m: +1 19:29:13 <nirik> t8m: +1 19:29:14 <kalev> t8m: +1 19:29:14 <mitr> t8m: +1 19:29:21 <t8m> myself is +1 19:29:25 <t8m> as well 19:29:39 <sgallagh> t8m: +1, but I'd like to see the warning period added into the proposal 19:30:00 <thozza> t8m: +1 with the warning period 19:30:23 <jwb> +1 19:30:41 <t8m> #agreed We will do the broken deps cleanup on Final Freeze from now on in the future Fedora releases (+8, -0, 0:0) 19:31:19 <t8m> #info There will be warning sent to the affected maintainers more at least 3 weeks in advance 19:31:30 <t8m> #undo 19:31:30 <zodbot> Removing item from minutes: INFO by t8m at 19:31:19 : There will be warning sent to the affected maintainers more at least 3 weeks in advance 19:31:36 <t8m> #info There will be warning sent to the affected maintainers at least 3 weeks in advance 19:31:47 <sgallagh> ack 19:31:55 <t8m> next topic 19:32:03 <nirik> we should ask jreznik to add this to the schedule, etc... 19:32:37 <mitr> Just added him to cc of the ticket 19:32:44 <t8m> #topic #1369 packages should disable internal crash handlers and depend on ABRT 19:33:48 <kalev> I am a little bit concerned that for some upstreams, it might work better to _not_ file crasher reports downstream and instead file the directly upstream 19:33:55 <t8m> I would say that FESCo could recommend that but it should not demand it. 19:33:58 <kalev> KDE seems to be doing it, for example 19:34:08 <t8m> yes 19:34:16 <nirik> yeah I wasn't sure of the kde case, but I think they are doing their own upstream thing 19:34:44 <mitr> kalev: Throwing away bug reports should pretty much never “work better”. The only case would be where upstream=packager but that is somewhat rare (and even more rarely constant) 19:35:35 <kalev> yes; I am saying that in cases where the fedora packages doesn't know the code very well and instead prefers upstream to handle it -- it might be better to have the crasher reports filed automatically upstream 19:36:04 <kalev> err, typos: should read "fedora packagers don't know" 19:36:18 <sgallagh> kalev: I think that's a problem better solved within ABRT 19:36:18 <mitr> kalev: I can see a case for having _both_ (though doing that might be technically difficult) 19:36:20 <thozza> kalev: the maintainer can always forward the crash to the upstream 19:36:21 <nirik> so, the main issue around this ticket seems to be poor multi arch support by some crash handlers... 19:36:40 <mitr> The interesting thing here is that if we ask for ABRT (presumably then asking package maintainers to help fix the bugs), we should be equally able to ask the crash handler maintainers to help port it to different architectures 19:36:42 <nirik> perhaps instead of some blanket thing here we could/should just look at breakpad? 19:37:30 <nirik> sharkcz: you happen to be around to provide input? 19:38:09 <mitr> nirik: c#9 lists other cases (though perhaps those are mostly already handled for multi-arch somehow) 19:38:18 <sharkcz> nirik: yes 19:39:42 <nirik> I'm not sure adding a "We recommend you disable any crash handlers in your package and use abrt" is really going to do much of anything... 19:40:04 <sharkcz> the breakpad was the recent case, but IMO there should be a recommendation how the crashes should be handled, if upstream wants them that's best, but there can lot of other pkgs which they do just some random action (from the distro point of view) 19:40:37 <thozza> sharkcz: like what? 19:40:48 <mitr> There is also an interesting side-question of opt-in/informed consent 19:41:52 <sharkcz> thozza: eg. they produce the backtrace to a file, keeping abrt out of scope (haven't checked though) 19:42:28 <t8m> Could we delegate this to FPC? 19:42:49 <kalev> they seem to have their hands full already ... 19:43:01 <t8m> I can't see us agree on a concrete directive here. 19:43:06 <thozza> sharkcz: ok, thanks for the example 19:43:22 <mitr> t8m: Why / why wouldn’t the same reason apply to the FPC? 19:43:36 <sharkcz> I think FPC would work on implementation, I would like to see a distro wide recommendation 19:43:41 <kalev> and also, I don't think the FPC is a good group for deciding policy 19:43:53 <kalev> we could ask them to come up with a specific guideline once we've decided what we want 19:43:57 <nirik> does the kde one work on all arches? 19:44:02 * nirik doesn't know much at all about it. 19:44:12 <t8m> mitr, I think we can't disallow all upstream crash handlers - for example I would not disallow the KDE one 19:44:41 <sharkcz> nobody suggests that 19:44:48 <mitr> I guess I am +0.7 to recommending that all package crashes are reported via abrt (if abrt supports that language), CONDITIONAL ON making this as automated as possible, not just a manual checklist item. (And that is -0 on forbidding other handlers) 19:45:34 <mitr> (as automated as possible might be search for known other systems, or perhaps also a text search for SIG{SEGV,ILL,BUS} ) 19:46:01 <mitr> Though this does not help sharkcz’s current predicament 19:47:03 <sharkcz> I have patched the spec for the recent pkgs, so I'm looking rather into the future 19:47:31 <kalev> what was the issue for the recent pkgs, does google breakpad client just not build on s390x ? 19:47:44 <sharkcz> also it would give a basis for opening bugs and potential discussions with maintainers 19:47:46 <nirik> looking for specific things like breakpad might be possible 19:48:01 <sharkcz> kalev: it doesn't build on any secondary arch 19:48:34 <sharkcz> another point is that breakpad likely should have been unbundled 19:50:15 <nirik> sharkcz: does it work on armv7? 19:50:24 <nirik> ie, all primaries? 19:50:25 <sharkcz> nirik: it builds 19:51:45 <sharkcz> they have files inside the code for ppc*/aarch64, but it doesn't build, so I choose to disable it as the buildsystem allows disabling 19:53:03 <t8m> I don't think we should solve google-breakpad build problems here. 19:53:08 <nirik> well, if it helps talking to maintainers I guess we could approve some recommends... but it seems half baked. ;) 19:53:52 <t8m> Unfortunately I do not see a clear proposal for the main topic here as well. Because it is unclear what the conditional on mitr's proposal concretely means. 19:53:55 * nirik guesses everyone else went off to nap 19:54:09 <t8m> nirik, +1 :) 19:54:13 <mitr> t8m: that means $somebody will write a rpmlint or fedora-packager patch 19:54:15 * thozza is here 19:54:37 <kalev> proposal: time for nap :) 19:55:10 <nirik> mitr: I fear if we do that... $somebody will == '\0' 19:55:14 <mitr> What is the next action for us to decide… 19:55:42 <mitr> nirik: That would, in my formulation, prevent the recommendation from becoming a part of the policy 19:55:42 <thozza> well, there is some recommendation in the ticket 19:55:46 <t8m> #proposal Postpone decision to the next week 19:55:51 <sharkcz> mitr: I might have some volunteers to actually write the code :-) 19:56:02 <mitr> sharkcz: I was hoping for that ☺ 19:56:24 <mitr> t8m: It’s not clear to me what will be different next week but we do seem to be in a nappy mood… 19:56:33 <nirik> I'd like to gather a bit more info on kde's crash handler too. 19:56:39 <nirik> so next week++ 19:56:47 <kalev> I can ask the KDE folks to chime in 19:56:48 <mitr> nirik: OK. t8m+1 19:57:05 <thozza> t8m: +1 19:57:05 <kalev> t8m: +1 19:57:08 <nirik> t8m: +1 19:57:08 <t8m> and that brings us to 19:57:14 <t8m> #topic Next week chair 19:57:24 <t8m> #undo 19:57:24 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x359bf6d0> 19:57:36 <t8m> #info Decision postponed to next week 19:57:40 <t8m> #topic Next week chair 19:57:51 <jwb> i'll be on PTO 19:57:55 * nirik notes next week is the day before thanksgiving holiday in the us... some us folks may be traveling then 19:57:56 <mitr> I will probably not be able to join next week. 19:57:57 <t8m> anybody volunteers? 19:57:57 <thozza> t8m: there is one more ticket, no? 19:58:11 <nirik> I can run it if no one else will... I should be around. 19:58:31 <t8m> thozza, which one? The F22 schedule will be discussed next week as jreznik will provide some proposal there. 19:58:51 <thozza> t8m: ok, I guess I missed some comments 19:59:10 <t8m> #action nirik will chair the next week meeting 19:59:18 <t8m> #topic Open floor 20:00:01 <thozza> proposal: end this meeting :) 20:00:19 <t8m> if nobody speaks up I will close the meeting in a minute 20:01:44 <t8m> #endmeeting -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
