Summary/Minutes from today's FESCo Meeting (2014-11-19)

[Tomas Mraz]

===================================
#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 at scrye.com>
18:08:31 <sgallagh> .hello sgallagh
18:08:32 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh at redhat.com>
18:08:38 <t8m> Hi all I apologize again
18:09:00 <thozza> .hello thozza
18:09:01 <zodbot> thozza: thozza 'Tomas Hozza' <thozza at redhat.com>
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