18:00:37 #startmeeting FESCO (2013-08-21) 18:00:37 Meeting started Wed Aug 21 18:00:37 2013 UTC. The chair is abadger1999. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:37 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:38 #meetingname fesco 18:00:38 The meeting name has been set to 'fesco' 18:00:40 #chair abadger1999 mattdm mitr mmaslano notting nirik pjones t8m sgallagh 18:00:40 Current chairs: abadger1999 mattdm mitr mmaslano nirik notting pjones sgallagh t8m 18:00:41 #topic init process 18:00:45 Hello all 18:00:52 morning 18:00:52 hi. 18:00:53 * notting is sitting in a different meeting, may not be fully here 18:01:01 have pitty for notting. 18:01:07 * mattdm mattdm ducked out of that meeting :) 18:01:10 * abadger1999 watches notting phase in and out of existence 18:01:20 I'm here-ish 18:02:03 IIRC mmaslano and t8m weren't going to be able to make it. 18:02:18 #topic #1077 Drop usage of --vendor from .desktop files 18:02:19 .fesco 1077 18:02:20 abadger1999: #1077 (Drop usage of --vendor from .desktop files) – FESCo - https://fedorahosted.org/fesco/ticket/1077 18:02:25 This is done. 18:02:38 Oops, t8m is here :-) 18:02:48 hello 18:03:04 had a badge issued to the list of people as a thank you. 18:03:17 I'll close this unless anyone wants to do more on it. 18:03:27 yay 18:03:39 * nirik notes we could look at badge rewarding other groups that help with things like this. might help them get done. 18:03:39 #topic #1148 F20 System Wide Change: Application Installer - https://fedoraproject.org/wiki/Changes/AppInstaller 18:03:41 .fesco 1148 18:03:43 abadger1999: #1148 (F20 System Wide Change: Application Installer - https://fedoraproject.org/wiki/Changes/AppInstaller) – FESCo - https://fedorahosted.org/fesco/ticket/1148 18:03:55 nirik: I think that would be a good idea to test out for a while. 18:04:12 for example, the long running systemd migrations stuff. 18:04:21 abadger1999: what happened to the glibc thing? was that first or last? 18:04:41 notting: First thing in the new business sectoin -- unless you would like it discussed now? 18:04:50 * abadger1999 is flexible 18:04:51 no, that works 18:05:00 Okay -- so App Installer. 18:05:11 The packaging team gave a list of requirements in the ticket. 18:05:32 There's been some back and forth with the Change Owners. 18:06:04 Note that mclasen is not an owner 18:06:10 From what I understand, the major question here is whether we consider 'yum history' to be a guaranteed stable API 18:06:21 In fact we haven't heard from rhughes in 3 weeks 18:06:27 sgallagh: and/or a *required* one 18:06:44 * nirik notes fedup already doesn't update/care about it. ;( Sadly. 18:06:49 mitr: He's the supervisor of the engineer implementing the App Installer. Functionally, he should be treated as an owner 18:06:53 if it's not required, the question of whether it's stable isn't really relevant 18:06:58 We have sort of decided that they have to agree :) 18:07:21 sgallagh: That would be a new mechanism :) but point taken, I was being pedantic 18:08:27 well asking to write to a database and at the same time saying "its a private db do not touch it" makes no sense 18:08:30 I'll note that we basically gave the packaging team veto power over the change when we accepted it so I think the burden's on the Change Owners at this point. 18:08:35 mclasen will be joining this meeting momentarily 18:09:04 drago01: That's not the case here 18:09:18 abadger1999: While that's true, the fact remains that they raised a valid point that there are multiple other pieces of the system apparently exempt from this compatibility 18:09:33 I think it's fair to revisit the question as to whether this is the right requirement 18:09:35 drago01: i'm fine with "if it's writing to it, it needs to write to it compatibly" 18:09:43 sgallagh: Did they? The other pieces of the system are not default with the exception of rpm. 18:09:56 And that's designed to operate at a lower level, not the same or higher. 18:09:59 abadger1999: I'd contest that RPM and fedup are fundamental 18:10:09 s/contest/contend/ 18:10:13 sgallagh: fedup is not as much exempt as "surprisingly not doing it" as I understand 18:11:01 $everybody was $always talking of fedup as "just a yum upgrade in a controlled environment" and it turns out it's not that 18:11:03 at least it was surprising to me, but I guess thats what I get for assuming it was using yum. ;) 18:11:04 not sure if hughsie is still around, but I talked to him this morning 18:11:23 mitr, +1 18:12:16 fedup-not-using-it bug: 18:12:20 .bug 979083 18:12:28 mattdm: Bug 979083 yumdb/history data is not available after upgrade from F18 => F19 (possible chroot problem?) - https://bugzilla.redhat.com/show_bug.cgi?id=979083 18:12:47 Well, the fact that we aren't mandating that calls to librpm or the rpm command-line tool also update this history suggests to me that we may have selected integration at the wrong layer 18:13:15 there's some history there... yum folks asked rpm folks for a db for this info and were told no. 18:13:25 sgallagh: yeah that's what I said in the ticket as well 18:13:27 mitr: eh, I don't think that's a fair criticism tbh 18:13:52 mitr: the real question is: if everything is expected to do something if it does yum-like things, how come using the yum api isn't enough to do that? 18:14:16 pjones: There's also the dimension of some callers not wanting to use Python / yum... 18:14:41 that's a separable issue about the choices we've made as fedora, though 18:14:47 pjones: b/c "the yum api". calling python from !python 18:14:51 sgallagh: I'm not actually sure whether it's "dnf has a plan that is just not implemented yet", or "dnf roadmap didn't account for PackageKit wanting a C API" 18:15:16 notting: which isn't impossible, it's just somewhat distasteful 18:15:31 pjones: also, the question of whether things are exposed in a reliable API-stable manner from yum 18:16:32 .... anyway.... 18:16:45 What do we have as possible solutions to the problem here? 18:17:00 As I understand the progress from the FESCo decision 2 weeks ago, _nothing is actually new_ except for the packaging team asking for explicit Fedora QA involvement. 18:17:03 ftr, I don't mind updating the yumdb or any other logs from the app installer. I'd prefer if it was automatic, and would require us to take locks 18:17:16 mclasen: would or would not? 18:17:20 Is the Fedora requirement a problem? 18:17:26 would not, of course 18:17:28 s/Fedora/& QA/ 18:17:35 mclasen: can't it simply run yum syncdb after each transaction? 18:18:13 drago01: hooray undocumented option 18:18:14 drago01: discussion in the fedup bug seemed to indicate that thats not the preferred way to update the yumdb 18:18:14 drago01: That would lose the scriptlet output, wouldn't it? 18:18:29 notting: https://bugzilla.redhat.com/show_bug.cgi?id=979083#c2 18:18:29 drago01: oh, wait, it's "yumdb sync" 18:18:31 yeah, that wouldn't give it all the info it normally has 18:18:35 notting: yeah sorry 18:18:51 I have no idea 18:19:13 just looks like a way to do it without having to worry about yum locks 18:19:55 * abadger1999 notes we've hit 15 minutes of discussion. 18:20:02 +1 to continue 18:20:12 (What are we actually trying to decide here?) 18:20:24 mitr, can I join your question? :) 18:20:28 mitr: yeah 18:20:49 * nirik is also +1 to continue if we can get some kind of proposals. ;) 18:20:54 * pjones as well 18:20:57 so currently I think things fesco could do: 1) allow discussion to continue on the ticket (alpha is coming up,though and we'd need a decision by then). 2) ask the App Installer owners to definitely say whether they can or cannot comply with the packaging-team's requirements 18:21:08 Straw-man Proposal: Withdraw the requirement to update the yum history and allow AppInstaller to behave as it sees fit 18:21:28 proposal: FESCo acknowledges comment#28 and asks feature owners to discuss this with Fedora QA. 18:21:37 * nirik re-reads to see what those requirements are again. 18:21:51 abadger1999: s/need a decision/need an implementation/ 18:21:55 sgallagh: -1 I'm still definitely for leaving the requirements to the packaging team... 18:22:15 abadger1999: What I hear above, change owners are fine in principle with updating yumdb 18:22:17 mitr: true that... so maybe we're already getting dangerously close to forcing a slip in the Change? 18:22:47 abadger1999: per the previous decision we'd be forcing the contingency plan already 18:23:10 mitr, +1 to your proposal 18:23:21 (after reading the comment #28) 18:23:48 or invoke the contingency plan 18:24:01 * nirik is +1 to mitr's proposal. -1 to sgallagh's. 18:24:14 sgallagh: 1) re yum history, I'm concerned about loosing it but could see a way to relax. 2) The working "to behave as it sees fit" is not acceptable to me. I'm not having two separate packaging universes that are allowed to ignore each other, if I can help it. 18:24:30 alpha freeze is 09-03 isn't it? 18:24:34 yes 18:24:35 * mitr really can't type today. 18:24:51 If we're voting, mitr: +1, sgallagh -1 18:24:56 mitr: "system("yumdb sync")" post-transaction seems to be an implied solution that is compatible per that comment #28 18:25:14 (at least, if 'yumdb sync' is incompatible with yum, we have larger problems) 18:25:55 Sure, I'm also -1 to my proposal, but I wanted us to explain our reasons at least. 18:26:13 I'm +1 to mitr's proposal 18:26:24 notting: maybe. The previous FESCo resolution "Approve the change conditional on 1) the packaging team and appinstaller both agreeing on a solution _and writing the solution down_" still applies I suppose. 18:26:57 mclasen: Refresh my memory what the specific sticking point is with the packaging team's requirements on you? 18:27:21 proposal#2: FESCo reiterates its 2013-08-07 decision and asks for the written down solution 18:27:22 interfacing with yum instead of dnf, right? 18:27:30 mitr: sure. but i would assume the package team can not be against *both* 'yumdb sync' or 'updates the yumdb with its own code' 18:28:14 notting: Yes. AFAICS from the locking standpoint there shouldn't be any difference either, I just don't want to get FESCo into specifying yumdb contents field by field. 18:28:49 sgallagh: there's no particular sticking point. I still think that this sort of history is ideally suited for the journal, but I seem to be the only one thinking that so far 18:29:08 we should really also (seperate from this) come up with a longer term plan. I mean, dnf is planned, but should yumdb/dnfdb get moved to rpm? seperate journal? etc 18:29:12 there's a general unease with the yumdb design and (lack of) api, too 18:29:28 notting: Couldn't they be given geppetto's statement that yumdb sync isn't meant for this purpose? (it's to fix things up after something messes up, not to record the full range of information)? 18:29:29 yes longer term plan 18:29:32 nirik: s/we/the relevant experts/ hopefully 18:29:38 mclasen: i wonder if just calling out to yumdb sync might be better short term until dnf comes up with a better api 18:29:53 sure, thats ok for me 18:29:55 abadger1999: that would imply that they are then ok with PK using its own code to write to yumdb 18:29:59 mitr: yeah. Just would love to see a written down plan. ;) 18:30:04 nirik: same here 18:30:05 notting: I think they said that.... 18:30:06 If there is a reasonable longer-term plan I'm happy with whatever ugly ting gets it working now. 18:30:21 I'll add this to the feature page 18:30:25 Proposal: recommend using yumdb sync for now, as well as asking the packaging and appinstaller teams to come up with a real long term plan for this _and writing it down_. 18:30:39 (possibly s/asking/requiring/) 18:30:45 notting: Last I heard, the packaging team was OK with app installer having its own code. 18:30:47 pjones: -1 18:30:55 (to the first part) 18:31:17 *we are seeing problems and conflicts that aren't there and don't need to be solved*, people 18:31:19 " would it be ok for you to implement a layer that would record AppInst? transactions into yum and/or dnf databases? If the answer is yes, I don't think we have any other problem here and the feature can be approved with this implementation as a requirement." 18:31:26 https://fedorahosted.org/fesco/ticket/1148#comment:21 18:31:47 abadger1999: hm. i find the "you must be 100% compatible" but "you shouldn't just call out to our code" does seem somewhat... obstinate? to me. 18:31:48 pjones: -1 18:32:08 notting: that's how it seemed at the time, too 18:32:22 pjones +1 18:32:24 well, yumdb sync doesn't have all the info that actually writing it would have... 18:32:31 notting: I read it just as stringent wording of a fairly ordinary requirement 18:32:32 pjones, -1 18:32:52 notting: well -- otoh, people are being asked to maintain two package managing stacks two releases before they wanted to do so. So.... 18:33:02 abadger1999: was there an answer to that? i'm not sure I see one. 18:33:14 nirik: true. but that's an additional amount of correctness 18:33:59 nirik: above in the meeting. "mclasen: ftr, I don't mind updating the yumdb or any other logs from the app installer. " 18:34:12 mitr: yeah, but from the package team side... ? 18:34:25 i am +1 to pjones, but also could be +1 to mitr's proposal, if pjones' doesn't pass 18:34:26 I guess the comment about asking qa to test. 18:34:39 nirik: comment#21 18:35:12 nirik: I thought of that as implicit in the packaging team's requirements -- "We're willing to keep the second stack working to high standards *if* the app installer owners are willing to do these things to not make our jobs harder" 18:35:18 'm +1 to the second part of pjones's proposal, asking for a written plan. 18:35:21 nirik: but yeah -- it wasn't explicitly stated. 18:35:27 note that if PK ends up writing to yumdb, there should also be notification to the appinstaller team if there are yumdb changes between releases (or in a release) before full dnf 18:36:04 Insiting on (yumdb sync) would be FESCo unnecessarily mandating a suboptimal solution when both parties are OK with doing better. 18:36:07 notting: ins't yum more or less in "maintaince mode" anyway? 18:36:21 mitr: yeah, that sounds right to me. 18:36:27 so, I am +1 to mitr's proposal, -1 to the first part of pjones and +1 to the second part and +1 to making it difficult for abadger1999 to count votes. :) 18:36:34 nirik: :-P 18:36:36 notting: which means don't really expect any such changes but who knows 18:37:11 drago01: for some value of more or less. but i think it's good to document that there is now an external user 18:37:26 notting: ok fair enough 18:37:58 I can second the nirik's vote - +1 to mitr's -1 to first part of pjones +1 to second and +1 to making it difficult to count votes :) 18:38:00 so where are we? 18:38:05 but please count it :) 18:38:20 I think maybe somebody should re-propose something they think is coherent ;) 18:38:26 and then we should vote on that. 18:38:28 ahoyhoy? 18:38:49 what does writing down a long term plan to do it right mean in the context of them having code to write to the yum db in the F20 version? 18:38:53 adamw: https://fedorahosted.org/fesco/ticket/1148#comment:28 is being looked at, which asks qa to test before beta that appinstaller handles yumdb transactions sanely 18:39:28 * abadger1999 goes looking at what the votes might stand at now 18:39:43 yeah, uh, reading c#28, i have to admit I have no idea what that would entail. 18:39:51 proposal: FESCo acknowledges comment#28 and asks feature owners to discuss this with Fedora QA. Further we ask packaging stakeholders to come up with a roadmap for dnf and yumdb and app installer items. 18:40:04 i don't know how to go about testing '100% compatibility with internal representations of entities in yumdb'. 18:40:14 (could phrase that better I know) 18:40:27 to be honest, I think that requirement is *bit* of an overreach 18:40:34 nirik: "FESCo reiterates its 2013-08-07 decision and asks for the written down solution. FESCo acknowledges comment#28 and asks feature owners to discuss this with Fedora QA. Further we ask packaging stakeholders to come up with a roadmap for dnf and yumdb and app installer items." ? 18:40:42 adamw: yeah, not fully sure either. I would more think 'not corrupted' and 'contains valid looking info' would be better 18:40:47 it's a nice goal, but it's very difficult to measure in any meaningful way 18:41:30 So if people are going to be held to it, we should define specific things like nirik just did (but even more quantifiable), and set up an evaluative criteria. 18:41:52 i'm a dumb test monkey, so mostly what i'd be _expecting_ to do in relation to a feature like this is some testing of the general form 'do a lot of stuff with yum and a lot of stuff with the new dnf-based apps and see if anything breaks' 18:42:14 if we want something more sophisticated than that then it's gonna require some help i think 18:42:17 adamw: I guess something like "both ways to install/update result in {structurally same changes to the DB, materially equal results when viewing the database}" 18:42:35 I agree "100% compatibility with internal representations of entities in yumdb" is too high a bar, unless packaging team provides a test suite. ;) 18:42:39 okay, now you're dumbing down to a level where i can play along. :) 18:42:40 Perhaps only the second part 18:42:43 Okay -- current vote 18:43:12 mitr's proposal passes: +1 t8m, nirik abadger1999 pjones notting 18:43:27 * abadger1999 notes mitr didn't explicitly +1 his own proposal. 18:43:40 +1 my very first proposal for the record 18:43:51 pjones proposal is at +4 to the second portion and +2 in its entirety 18:44:15 I think I missed pjones' proposal 18:44:24 I think if we want to go ahead with the second portion, nirik's phrasing is better. 18:44:31 the idea would be to test for db representation consistency in both app installer and yum before beta? 18:44:35 mclasen: does that work ok for you? or do you still have concerns/issues? 18:44:40 tflink: yes 18:44:54 Oh sorry, that was mitr's phrasing, not nirik's. 18:44:56 I'm +1 for mitr's proposal in any case 18:45:11 or rather, mitr's phrasing of nirik's proposal 18:45:48 nirik: sounds like a lot of concern about something that hasn't really figured in qa plans at all so far (or have we been testing 'yumdb structural integrity in the past ?) 18:46:04 mclasen: not directly ,no 18:46:06 as long as we're only expected to call yumdb sync in a strategic place, thats ok with me 18:46:39 well, the plan was to talk to it directly I thought... which it sounded like there already was code for. 18:46:41 Hmm... then it may fall apart -- I don't know that that's what the packaging team had in mind. 18:46:53 yeah, what nirik said. 18:47:24 * abadger1999 notes we're at 46minutes into the meeting 18:47:29 I don't know about any code to 'talk directly'. as far as I know, the yumdb is just a pile of files somewhere 18:47:32 Does anyone have a hard stop today? 18:47:33 abadger1999: Don't need to solve this, we wan't a written agreed plan, let them figure it out :) 18:47:35 I will have to investigate 18:47:53 abadger1999 my head is slowly slipping and will hit the table eventually, so there's that 18:47:54 mitr, +1 18:48:03 mattdm: Buy a pillow ;-) 18:48:25 Trust me, it'll come in handy for other meetings too ;-) 18:48:42 mclasen: it's a sqlite db I think... but "I'm happy reading and writing to the yumdb if the yum team are happy with this. I got in a lot of trouble when Zif started writing to it in the past, so I don't want to add support without at least a +1 from someone like zpavlas." 18:49:00 nirik: no it isn't afaik 18:49:13 ok. Doesn't matter. it's some bits somewhere. ;) 18:49:28 nirik: it is a folder / files structure thing (this is why I call it "non db") 18:49:35 ok. 18:49:46 okay... as mitr says, I think we're at implementation details without one of the parties involved. 18:49:55 abadger1999, exactly 18:49:57 So let's leave this topic. 18:49:59 * nirik nods. 18:50:02 next topic please :) 18:50:19 A moment... 18:50:24 nirik: ls /var/lib/yum/yumdb ;) 18:50:31 #info mitr's proposal FESCo acknowledges comment#28 and asks feature owners to discuss this with Fedora QA. accepted +7:0:0 18:50:49 Does any fesco member have a hard stop in 10 minutes? 18:50:55 * nirik doesn't 18:51:03 Proposal: Further we ask packaging stakeholders to come up with a roadmap for dnf and yumdb and app installer items (the final state palnned for ~F22). 18:51:20 mitr: definitely +1 to that 18:51:23 +1 18:51:26 mitr, +1 18:51:27 mitr: +1 18:51:30 sure, +1 18:51:33 what does "final state" mean? 18:51:41 other than that, I'm probably +1 18:51:45 mattdm: "no currently forseeable changes" 18:52:01 mattdm: he means "where we want it to be when it all lands in F22" 18:52:04 I think. 18:52:16 pjones okay that I'm good with 18:52:36 mitr: that's what you mean, right? 18:52:55 #info Proposal: Further we ask packaging stakeholders to come up with a roadmap for dnf and yumdb and app installer items (the final state palnned for ~F22). accepted: +6:0:0 18:53:06 pjones: yes. 18:53:09 #topic BlueZ System Wide Change - https://fedoraproject.org/wiki/Changes/Bluez5 18:53:12 * nirik notes also some of this would be good to know for the fedora.next planning. 18:53:29 There's no ticket for this in fesco's trac due to us voting on it early I think. 18:53:47 yeah 18:53:49 There's been extensive discussion on the mailing list and we have to keep track of one thing to evaluate it later. 18:54:33 should we file a ticket to note that/trac it? 18:54:37 Whether the other desktops are: (a) okay with having bluetooth broken for them (b) have a solution in place (c) object to the change. 18:54:43 yeah 18:55:01 abadger1999: yeah, you were faster than me, I'll create ticket 18:55:08 jreznik: Cool. 18:55:26 Does anyone have an idea of who we should ask to state a position for each desktop? 18:55:29 abadger1999: I doubt very much that (a) is ever valid 18:55:37 Is parallel-installation possible? 18:55:40 no 18:55:45 sgallagh: according to the ml, no. 18:55:50 sgallagh: I think someone mentioned xfce is actually in that position 18:56:04 not that I know of, no. 18:56:09 mitr: XFCE is okay with no bluetooth? 18:56:18 There's a very early xfce applet... it's not likely to be very usable for f20. 18:56:22 My impression from the thread was that nobody was explicitly objecting, and most were working to get something done. 18:56:48 I'm fine with no bluetooth tho, as I don't want to hold back other desktops with more resources. If people find this horrible, they can step up to help with the applet. ;) 18:57:06 I saw some objections but I'm not certain that they speak for the desktops. 18:57:12 nirik: OK, I miunderstood. Sorry. 18:57:34 Are both GNOME and KDE functional at the moment? (Those are generally our two blocker desktops) 18:57:36 as soon as the applet is usable I intend to ship it, and likely it will get better over time for f20 users. 18:57:41 drago01: hadess implied that parallel *packaging* was possible. they just couldn't be installed simultaneously 18:57:42 Sorry, I haven't been following that thread on the ml 18:57:55 sgallagh: rdieter packaged bluedevil snapshot as far as I know 18:58:12 there are still some features missing, upstream working on it right now 18:58:24 kalev and raveit65 were working on a applet for mate and other desktops with systray 18:58:28 sgallagh: there's still time till the alpha freeze 18:58:36 for gnome, we also still need nm and pa updates 18:59:04 mclasen: What is "pa" in this context? 18:59:09 pulseaudo 18:59:13 audio, even 18:59:19 * sgallagh nods 19:00:04 * jreznik would really like to see alpha change deadline as the point to start contingency plan - it's quite a big thing to go with or revert on time 19:00:05 proposal: keep an eye out on progress, revisit as and if needed? 19:00:53 nirik: Is that different from "not keep an eye on progress"? 19:01:06 nirik: pretty much :-) I think that's the default :-) 19:01:07 would fesco allow conflicting bluez and bluez5 packages? 19:01:19 well, counter proposal would I guess be: don't file a ticket, revisit at change freeze to see if it needs contingency plan 19:01:34 notting: would this impact the multi-desktop DVD? 19:01:39 mitr: no 19:01:40 Proposal: if BlueZ isn't ready by alpha, start contingency plan and allow conflicting bluez/bluez5 packages 19:01:48 multi desktop are several spins on one dvd 19:01:50 mitr: that's separate lives, so no. 19:01:52 (so that development can proceed for F21) 19:01:52 notting: That would be FPC. 19:02:20 I've been thinking about having FPC reevaluate that as a whole but it might not be discussed and voted on in time for alpha. 19:02:37 abadger1999: exception for bluez5? 19:02:39 abadger1999: ? we have conflicting packages in repo, don't we? 19:02:51 sgallagh: I'm not sure about yanking a month of time from people actually writing code like this. 19:02:52 sgallagh, what problems would be with conflicting bluez/bluez5 packages? Some desktops would not be installable in parallel? 19:03:10 t8m: Exactly 19:03:16 I don't like tish 19:03:18 notting: ohh... Actually already covered. 19:03:20 this 19:03:27 mitr: I'm not talking about taking a month away, I'm talking about adding 7 months :) 19:03:29 http://fedoraproject.org/wiki/Packaging:Conflicts#Compat_Package_Conflicts 19:03:40 That's couched in terms of file conflicts as the justification. 19:03:59 So compat bluez package smight violate the spirit but not the letter of that guideline. 19:04:55 sgallagh: Development for f20 should already be in process (we gave teh Change the go ahead last week). 19:05:04 t8m: Well, it's not ideal, but IMHO it beats the alternative of having no support in some desktops 19:05:16 is dbus interface the issue for parallel installation? shouldn't be possible do the same as with NM? (yeah, it caused a lot of troubles...) 19:05:25 sooo, what's wrong with the contingency plan as written in the change page? 19:05:53 sgallagh, that's tru 19:05:55 just that the beta change deadline seems too late? 19:06:27 mattdm: Yeah, I don't like seeing a major piece of functionality reverted at that late date 19:06:40 mattdm: also -- Change was submitted late so we made it potentially block on other desktops, not just gnome+kde. 19:06:41 mattdm: for me it really seems too late, pretty widespread to revert for final 19:06:56 I don't think there's likely to be enough time to retest sanely before final 19:07:25 Frankly, if I'd realized how much trouble this was going to be originally, I'd have voted to defer it to F21 in the first place. 19:08:02 so is there proposal for earlier date to invoke the contingency plan? 19:08:03 (of course, that probably would have meant that no one would have bothered to deal with it until branch of F21, leaving us in the same position...) 19:08:13 t8m: That was my proposal above 19:08:25 sgallagh: kalev invested quite a lot of work coordinating stuff, so I'd trust him at least for now 19:08:31 Proposal: if BlueZ isn't ready by alpha, start contingency plan and allow conflicting bluez/bluez5 packages 19:08:51 ah ok 19:08:51 sgallagh: the underlying problem is that it is not parallel installable, pushing it out won't get you out of that 19:09:04 I can amend that to "if kalev says at alpha 'we're definitely going to make it', revisit then" 19:09:25 mclasen: No, but it gains us six months to add support to the other desktops in Rawhide 19:09:29 your contingency doesn't seem to work. 19:09:30 mclasen: Doesn't allowing conflicts get you out of that? 19:09:31 * nirik is fine punting to before alpha change deadline... there's really actually a lot of work going on. 19:09:32 Alt proposal: accept plan is as is, except contingency plan deadline at alpha 19:09:34 sgallagh: -1. I'd be open to moving forward the contingency activation ~2 weeks 19:09:40 abadger1999: no? 19:10:02 abadger1999: I mean, they're not going to magically both work just by us taking away the requirement that causes them to not both be allowed. 19:10:06 +1 mattdm (alpha change deadline right? not alpha release?) 19:10:18 nirik yes 19:10:22 mattdm: +1 to alpha change deadline 19:10:42 Perhaps we should just agree to revisit progress at Alpha change deadline, reserving the right to invoke the contingency plan at that time (but no earlier)? 19:11:04 pjones: I'm not understanding something... I thought, if old is installed bluez and not the new one things linked to it work. If new bluez is installed and not the old one, then things linked to it work. 19:11:13 Conflicts prevent the two from being installed at the same time. 19:11:18 sgallagh: I can agree to that without actually changing my opinion :), so.... 19:11:45 Which is the road to icky but gets around the problem of non-functional programs installed. 19:11:52 abadger1999: but you still can't actually have both dep chains installed at the same time 19:11:57 mitr: Yeah, I think it's reasonable to just say we'll decide whether an extra week or two is warranted at that point 19:12:00 pjones: correct. "road to icky" 19:12:24 sgallagh, +1 19:12:42 adamw: So to be clear -- we still have the previous acceptance criteria. We're just *adding* contingency plan change to alpha? 19:13:12 err 19:13:15 mattdm: ^ 19:13:49 Previous acceptance criteria is: http://www.fpaste.org/33861/77112410/ 19:13:51 abadger1999: I think the proposal is moving it from beta to alpha 19:14:02 yeah, what nirik said. 19:14:23 s/Beta Change Deadline/Alpha Change Deadline/ in the proposal 19:14:48 http://fedoraproject.org/wiki/Changes/Bluez5#Contingency_Plan (change that here) 19:15:20 mattdm: right.. I mean -- we aren't dropping the previous criteria. We're just adding a new criteria "We will do the contingency plan evaluation at alpha, not at beta". 19:15:46 hm 19:16:05 given that it implies new work to adapt, moving contingency *up* seems somewhat self-defeating 19:16:24 b/c the previous criteria included non-release-blocker desktops and I want to know that we're on the same page about that. 19:16:41 the alternatives are a) defering to f21 b) accepting the risk that beta is not enough time to back out 19:17:09 or c) to hack in the bluez5 package, which might not be much less work than b). 19:17:22 mclasen: what is the mechanism NM uses to talk to bluez? 19:17:36 mclasen: (similarly, PA) 19:18:20 abadger1999: I'm still ok with that provided we can figure out who speaks for each. 19:18:21 abadger1999 Ah I see what you're getting at. Do we have a good mechanism (or history, for that matter) for getting that? I think we _definitely_ need a reasonable deadline for such objections 19:18:33 in f19, looks like NM would use dbus, PA uses library linking 19:18:42 but really, I know kalev is working on an applet, so all this gnashing of teeth may be moot in a week or two 19:18:56 so a 'conflicting packages' scenario implies PA-module-bluetooth and NM's bluetooth only works on one of the two package sets 19:19:41 notting: I don't know 19:20:23 proposal: defer and see where we are next week 19:20:24 notting: Good point. 19:21:17 and if it's talking to those things that people would need an old-version applet for, conflicting packages therefore may be a pointless solution 19:21:18 nirik, +1 19:21:31 nirik: I'll add -- ask on devel@ for desktop owners to register any objection. 19:21:36 sure 19:21:42 i'm only +1 to defering if we promise to time-box the conversation next week :) 19:21:42 abadger1999, +1 to that as well 19:21:56 +1 19:22:07 nirik: ok, can live with that. +1 19:22:40 if there's a working systray applet in the next few weeks we should be fine. 19:22:44 19:22:53 That's +5. 19:23:15 #info defer and see where we are next week and ask on devel@ for desktop owners to register any objection by next week 19:23:32 #topic https://fedoraproject.org/wiki/Changes/GLIBC218 19:23:36 Something easy I hope 19:23:49 * sgallagh sighs. Twenty minutes of arguing to decide not to decide. 19:23:57 This got lost in the shuffle because it should be a systemwide change but hte owner didn't update the Change. 19:24:25 I really don't like the precedent, but, ... it's glibc and it's been built already, so +1? 19:24:27 Since it's past the deadline, I think that means we reject it automatically (kidding!) 19:24:27 It's presently in rawhide/f20 19:24:29 sure, +1 19:24:44 +1 rubber stamp 19:24:45 +1 19:24:49 +1 19:25:13 +1 19:25:14 +1 19:25:34 #info GLIBC2.18 Change Approved +6:0:0 19:25:53 #topic #1157 change the way Initial Hosting Requests are processed 19:26:06 .fesco 1157 19:26:09 abadger1999: #1157 (change the way Initial Hosting Requests are processed) – FESCo - https://fedorahosted.org/fesco/ticket/1157 19:27:31 nirik: Do you have some ideas about this? Should we just leave it to infra whether to implement it? 19:27:34 I'm not sure it's too feasable to match people with sponsors before they submit everything, but I could be wrong. 19:28:17 well, there's an infra side to it, and then a sponsoring workflow side (which is more fesco's business) 19:28:48