18:01:22 #startmeeting FESCO (2015-01-07) 18:01:22 Meeting started Wed Jan 7 18:01:22 2015 UTC. The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:22 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:01:22 #meetingname fesco 18:01:22 The meeting name has been set to 'fesco' 18:01:22 #chair dgilmore jwb kalev mattdm mitr mmaslano nirik sgallagh stickster t8m thozza 18:01:22 #topic init process 18:01:22 Current chairs: dgilmore jwb kalev mattdm mitr mmaslano nirik sgallagh stickster t8m thozza 18:01:30 hi all 18:01:31 morning everyone. 18:01:37 hi 18:01:38 hello 18:01:39 * mattdm crawls out from cave, blinks in sunlight 18:01:43 good evening everyone :) 18:01:50 * mattdm notes that it's going to be six more weeks of winter 18:01:54 * mattdm goes back into cave 18:01:57 .hello sgallagh 18:01:58 sgallagh: sgallagh 'Stephen Gallagher' 18:02:11 .hello mattdm 18:02:13 mattdm: mattdm 'Matthew Miller' 18:02:19 Hello 18:02:24 hey 18:03:17 hello 18:03:38 * jreznik is around, on the team meeting - ping me when you'll need me 18:04:22 OK, that looks like almost everyone, so we can just get started 18:04:36 #topic #1372 "Workstation" Product defaults to wide-open firewall 18:04:36 .fesco 1372 18:04:37 sgallagh: #1372 ("Workstation" Product defaults to wide-open firewall) – FESCo - https://fedorahosted.org/fesco/ticket/1372 18:05:16 are the various stakeholders in attendence? 18:05:30 I saw twoerner. I haven't seen Bastien. 18:05:56 sgallagh, hadess is here 18:06:02 sgallagh, you're not looking hard enough :) 18:06:14 I am afraid there is no solution that is acceptable to everyone. 18:06:20 Ah, I didn't realize that nick matched that name 18:07:13 So, before we start arguing about solutions (short- and long-term), I was hoping we could discuss goals 18:07:31 I don't think anyone is perfectly happy with the current state (is that a fair statement?) 18:07:51 fair understatement, maybe even 18:08:01 I'm not sure we need to discuss solutions here tho... 18:08:10 nirik, +1 18:08:15 unless we feel that it's worth overriding the workstation working group. 18:08:20 sgallagh: I am reasonably happy with the current capabilities _of the firewall_ actually. I am very much wishing for reliable sandboxing which would replace some of the firewall uses but is not actually a firewall. 18:08:22 which IMHO, I am -1 to 18:08:25 nirik: Well, we need to try to agree on an end-experience, not necessarily an implementation 18:08:38 mitr, +1 18:08:41 the long term goals were mentioned in my mail to fedora workstation, definitely not finished, but certainly on the right path 18:08:52 sgallagh: we do? isn't that for the workstation working group? 18:08:53 I'm not explaining myself well enough 18:09:02 please explain more. 18:10:22 /me tries to find appropriate phrasing 18:11:52 Somewhere, someone needs to make a decision where on the Usability<->Security continuum the default Workstation environment belongs. This should probably be the Workstation WG, but I argue that it's sensible for FESCo to provide guidance 18:12:06 i disagree. 18:12:42 if it were sensible, then FESCo would have given that guidance long before now. like the first time this all came up 6 months ago 18:13:14 i think that we've shown that the workstation WG can talk to security folks like mitr and twoerner when changes happen 18:13:18 Well, the guidance we gave was "have the firewall and desktop people talk it out and come to a decision" 18:13:32 The current setup is not ideal, but I trust the workstation folks to have made the best choice they could with what they have... 18:13:32 and that decision was made 18:13:33 that seemed to work pretty well, I should point out 18:13:37 The communication kind of failed and both groups came away from the discussion with a different understanding of what was decided 18:13:39 jwb, didn't it actually give at least vague guidance that the firewall should be there 18:13:46 t8m, no 18:13:55 jwb: actually yes, at least partially 18:14:08 jwb, i have to disagree 18:14:11 sgallagh, it didn't fail, no 18:14:17 the proposal was "no firewall at all" and fesco voted against that 18:14:18 hadess: I do not agree 18:14:28 t8m, mattdm: and the existing solution has a firewall 18:14:41 hadess: Judging from the amount of "We were strong-armed into agreeing" I heard from the firewall folks, I think it did 18:14:42 jwb, i am not saying it does not 18:14:45 sgallagh: I don’t necessarily think that FESCo should make that kind of guidance. I do think that because the original discussion happened in FESCo and was rejected, the new proposal should have gone to FESCo—not because FESCo necessarily has or should have the authority, but because that’s where everyone _expected_ the follow-up; hence the current blowback. 18:14:48 twoerner, you don't agree, but mitr did, he hopefully still does 18:14:50 twoerner: could you share what you would like to see here? 18:15:11 sgallagh, the problem seems to have been that i talked to one person not two, and they don't agree 18:15:21 sgallagh, hadess: For context, I am not a “firewalld developer”. 18:15:47 hadess: That would qualify as a communication failure. Not necessarily anyone's direct *fault*. 18:16:33 I'm not looking to assign blame. Just to recognize that the communication was at least *incomplete* and therefore we ended up not getting the agreement we really sought. 18:16:33 failure to reach an agreement on every detail is not a communication failure. Sometimes, people just disagree 18:17:08 I will be accountable for agreeing to this plan, I do think asking the user only once for communication/sharing decisions makes sense in principle. As for the communication, I was not happy with the decision to move this to desktop@ but I didn’t feel necessary to raise a pointless stink about it at the time. 18:17:15 mclasen: Failure to talk to the right people is a communication failure. 18:17:39 who decides who the right people are ? 18:17:41 let's focus on moving on, and not the definition of communication 18:17:47 mitr, you've seen how it ended up on devel@, i'm completely happy with that decision :) 18:17:49 jwb: yes 18:17:51 so what do you want to actually accomplish here? 18:17:54 jwb, +1 18:18:09 hadess: Hiding from people who disagree with you is not really making things better, _especially_ when they later find out (like they did). 18:18:25 * nirik would like to hear from twoerner on that since I think he disagrees with the current setup... 18:18:38 What I want to accomplish is this: agreement that the current state of things is not immutable and reopen the conversation for a usable AND secure default. 18:18:55 sgallagh: I don't think anyone says this is immutable. 18:18:56 twoerner: what's the problem with current setup? 18:18:59 Primarily, kkofler raised this. 18:19:24 nirik: I voted against the use of the current workstation zone 18:19:35 I believe it is mainly about expectations. 18:19:50 what I want to accomplish (at least right now without more info otherwise): Close this ticket and say work with the workstation group on improving thnigs, we are not going to override them on this and we trust their judgement. 18:20:14 For example, I would be happy with us shipping several different default firewall configurations (or at least, just two: "Recommended" and "Paranoid") 18:20:22 kalev: that the ports above 1024 are completely open 18:20:26 And documenting well how to use them 18:20:28 twoerner: ok. you want it to block >1024 ports by default? and break those apps that need that open? 18:20:33 * mclasen waits for the suggestion to ask in the installer 18:20:50 mclasen: no no, we need a popup! 18:20:56 mclasen: No, we've been over that before. That's the wrong answer. 18:20:58 sgallagh: Where “firewall configuration” is what? A package? A command to type? 18:21:06 But a simple Firewall selection in GNOME Settings? 18:21:07 Because we seem to have that command :) 18:21:08 Maybe 18:21:08 I there is a general expectation that Fedora has a firewall preventing outside connections to random (even 3rd party) software running on the computer, then we have a problem with the current configuration. If the expectation is not such, then we don't. 18:21:09 so that for example databases are reachable for everyone, which is bad on a (web-)development machine 18:21:16 sgallagh: we have that. 18:21:22 If there... 18:21:33 sgallagh, there's already a "paranoid" setting available from the UI, though the default zone cannot be changed in the UI 18:21:58 twoerner: meh. I don't care if a database server is reachable for everyone on my home network. 18:22:04 twoerner: which the user installed and setup... so, it's the expectation you are objecting to? 18:22:14 t8m: The underlying assumption to that expectation question is that the passively listening / actively connecting distinction matters. And nowadays, with ISPs injecting JavaScript into others’ responses, it doesn’t all that much. 18:22:15 nirik: there was a nice proposal for a layer in the desktop 18:22:25 which applications needs ports >1024 to be open to work properly? 18:22:26 twoerner, it was awful UI 18:22:47 layer? 18:22:48 firewallds configuration is just not ready for a ui 18:22:49 mattdm: I agree for @home.. but the workstation zone is also used for public (open) wifis by default 18:22:49 mitr, I think it is more a publicity problem than a real security problem :) 18:22:53 OK, we shouldn't get into the details here. 18:23:04 thozza, they're listed over and over again in the thread, at least half-a-dozen applications in the default install 18:23:05 sgallagh++ 18:23:07 going to a internet cafe is bad with this 18:23:16 I'd be fine with us all coordinating on a chapter in the admin guide on how to set this up to your individual specifications 18:23:37 twoerner: if you install and configure and run apps on >1024... sure, but if you do that you can easily change the fw zone too. 18:23:45 twoerner, not any more than it was before, really 18:24:25 twoerner: Going to a internet cafe with a database server you configured yourself and a database hacker at the next table would be bad... all the sharing software installed by default should be turned off automatically on unapproved networks. 18:24:27 right, so going back to the initial statement in this discussion.... UI improvments could open up more options that everyone could feel better about, right? 18:24:41 twoerner: which database listens on all interfaces by default? 18:24:55 twoerner: that sounds like a bad practice regardless of firefwall presense 18:25:01 apologies for dropping off. i had a power outage here 18:25:06 win 14 18:25:09 mcatanzaro: should? which service is doing this? 18:25:35 hadess, gnome-settings-daemon? (?) 18:25:45 drago01: yes it is 18:26:01 twoerner, currently gnome-settings-daemon for a number of services, in the future, we'll be able to use sandboxing to make this better 18:26:07 mcatanzaro: so all database services are using gnome-settings-daemon?? 18:26:48 mcatanzaro: as Workstation is meant for developers there is more than gnome-* 18:26:51 mattdm: I don’t think hoping for UI improvements is realistic. Because there are the two bounds of making the UI precise enough to be pointless for many users (”do you want IPv4 connections to 192.168.1.3, which is en2p0, port 5353, to succeeed”?) and making the UI nice enough to be useless (“You have a database running. Do you want to make it functional?”) 18:27:51 * mitr tries a set of completely orthogonal proposal to hopefully focus this… 18:27:54 mitr: I'm thinking more like: having fewer zones, and having zone selection more discoverable from the gnome/networkmanager ui 18:27:56 twoerner: ok so which db does that? 18:28:26 drago01, any random third party db 18:28:29 so i take it we've moved from "let the Workstation WG discuss/decide this" to "FESCo needs to discuss implementations"? 18:28:37 apparently 18:28:46 t8m: oh so you don't mean the ones we ship ok 18:28:48 amazing how quickly that happened. the power was only out for about 2 min here 18:28:48 mattdm, i already explained that zones aren't a good match for something user visible 18:28:53 jwb you're right; can we pull this back? 18:29:02 drago01, it does not matter actually - the local firewall was invented for exactly that purpose 18:29:06 * kalev is for pulling back too. 18:29:08 I'd really like us to at least first agree that everyone involved is trying to get to a common point: Only the things we want people to be doing are open by default. The first part of that is highly fluid. 18:30:11 t8m: Which is also exactly the kinds of applications where we can never do a good UI, it’s either “these work by default” or “these don’t work by default” (or, the worst of all, “users are trained to run arbitrary internet-provided commands as part of installation of ordinary software”) 18:30:12 not sure how that helps us, until the neural brain plug interface happens so we know what the user intends. ;) 18:30:17 I think "Shut everything off unless the user explicitly opens it" is just as wrong a choice as "Well, users don't know how to use a firewall, so just shut it off" 18:30:23 There's got to be a sensible middle-ground 18:30:42 sgallagh, really? 18:30:46 sgallagh, i don't think i can find an agreement with twoerner, given the discussions we had since we got into an agreement with mitr 18:31:00 sgallagh, I don't actually believe much in that. 18:31:24 proposal: close ticket, ask interested parties to continue to work with the workstation group to improve things. 18:31:37 nirik, +1 18:31:38 nirik: We just had people stating that they don't think they can 18:31:46 s/people/the relevant people/ 18:32:07 sgallagh: No, there really isn’t. Even beyond the widespread practice of using port 80/443 fo everything _to bypass firewalls_, you can never let the user decide that “this weather application with nice animations is allowed to connect to weather.com but not to tor or IRC”, the situation is actually fairly hopeless. 18:32:11 nirik: +1 18:32:13 sgallagh: which is too bad, but you can't make everyone agree all the time. 18:32:23 well maybe we could also somehow approve (or disapprove) the current situation as acceptable (or inacceptable) 18:32:36 sgallagh: I don't think they said they can't work with the Workstation wg; they said they don't agree -- there's a difference 18:32:47 Proposal 1) If the Workstation WG really doesn’t want FESCo {review,second guessing}, they are welcome to not ask for it for the configuration of their product. (FESCo may still raise some egregious issues but this proposal implicitly defines the firewalld default as not that egregious). 18:33:08 mitr: the workstation working group did not file this ticket. 18:33:08 Proposal 2) The automated tests to make sure that nothing in Fedora is listening by default unless on a strictly maintained whitelist are a blocker for F22. 18:33:13 it was a user trying to override them 18:33:24 nirik: True; I believe the outcome would follow. 18:33:42 mitr, 2) was planned for f21, but taskotron never got to the point where it was usable for this purpose 18:33:46 Proposal 3) Find someone interested in editing the release notes or otherwise highlighting this defaults change for long-term users. 18:33:49 nirik: they filed the original change request 18:33:55 mitr, i doubt it is now 18:33:56 mitr: Why does "following our established guidelines" have to be automated here? 18:34:01 hadess: IMHO that should have been a _blocker_ for making that config change for F21. A Blocker means a blocker. 18:34:21 to be clear I think it's fine that someone took something to us if they disagreed with a working group decision. In this case I don't agree the thing is something we want to override for and should be closed->wontfix 18:34:21 sgallagh: What is this in reference to? 18:34:33 "Proposal 2) The automated tests to make sure that nothing in Fedora is listening by default unless on a strictly maintained whitelist are a blocker for F22." 18:34:35 nirik +1 18:34:46 mitr, given that i can't strongarm people into working on taskotron faster, that means pushing it back indefinitely 18:34:58 We already have that stated explicitly that nothing can listen (externally) by default without permission 18:35:02 sgallagh: Because we did have bugs in this area, and this is one of the few cases where firewalls are actually useful (and why everyone so desperately wanted them in the 1990s) 18:35:06 mitr: if you can get QA buyin for such work, ok... but that sounds like a unfunded mandate. ;) 18:35:08 we have 4 different proposals 18:35:15 this is kind of a trainwreck 18:35:24 mitr: Well, forcing the firewall to work around process failures is a bad idea 18:35:32 everything we do in fedora is unfunded...sad reality 18:35:58 OK, let's take this back to the very top-level. 18:36:05 hadess: No, that would mean pushing other Workstation work back. 18:36:27 Proposal: FESCo trusts the Workstation WG to properly research and develop a sensible firewall solution and will stay out of the way. 18:36:28 mitr, there's no one in workstation qualified to do that 18:36:31 (Noting that 1) would make 2)3) obsolete) 18:36:43 mitr, presumably there's nobody in your team to work on it either 18:37:13 sgallagh: +1 18:37:17 hadess: So somebody should learn? And I would argue that those changing the steady state :) But that is really not a FESCo matter. 18:37:20 sgallagh, +1 18:37:28 mitr, +1 18:37:30 (For the record, I am +1 to my own proposal) 18:37:35 sgallagh: +1 18:37:48 sgallagh: +1 18:37:57 mitr, so tell me why the security folks aren't the ones working on that? 18:38:00 sgallagh, this is equivalent to mitr's proposal 1) 18:38:01 (I also volunteer my own time to the Workstation WG if they want to consult me for input) 18:38:07 sgallagh: We see they didn't do that, so what guarantees that they will? 18:38:14 sgallagh: I’m not so sure. I _am_ fairly happy with the status quo but #1301 really wasn't trust-inspiring. 18:38:33 sgallagh: (it passed anyway so just for the record.) 18:38:35 sgallagh, +0 18:38:40 sgallagh: +0 I guess. 18:38:47 +0, too 18:38:49 mitr: Safe bet that the status quo will prevail, at least in the mid-term. 18:39:25 I've got (+5, 3, -0). 18:39:32 hadess: To the extent I have any influence in that, making DLNA work is not even at the bottom of the priority list. 18:39:46 sgallagh: one vote from t8m was for mitr 18:40:04 #agreed FESCo trusts the Workstation WG to properly research and develop a sensible firewall solution and will stay out of the way. (+5, 3, -0) 18:40:11 thozza: I know; I counted him as +0 18:40:12 thozza, he voted for himself, it is correctly counted 18:40:18 ahh, ok 18:41:07 #info sgallagh volunteers to act as a security consultant to the Workstation team if they are interested. 18:41:13 #topic #1349 Fedora 22 scheduling strategy (and beyond) 18:41:13 .fesco 1349 18:41:15 sgallagh: #1349 (Fedora 22 scheduling strategy (and beyond)) – FESCo - https://fedorahosted.org/fesco/ticket/1349 18:41:20 mitr, working on regression testing server packages that go in fedora should be 18:42:04 So... we've left this decision long enough, yes? 18:42:15 we have a very rough schedule at http://fedoraproject.org/wiki/Releases/22/Schedule 18:42:17 FWIW, I found one thing listening on my laptop >1024. unbound-control. Guess I should file a bug on it. 18:43:17 I'm fairly comfortable with the proposed schedule. 18:43:28 i think it's as good as it's going to get for now 18:43:30 nirik: if on all interfaces, we should change it 18:43:31 seems fine to me. 18:43:38 I also like that we enter Alpha Freeze shortly after DevConf.cz, so we should be able to use the hackfests there to good effect. 18:43:55 #link http://fedoraproject.org/wiki/Releases/22/Schedule 18:44:13 oh, it is localhost. nevermind. ;) 18:44:21 so, that means change submission deadline in _less than two weeks_ 18:44:24 I'd suggest that we schedule the mass rebuild for seven days before Alpha freeze 18:44:35 mattdm: yes 18:44:35 jreznik: ping (this is likely important to you) 18:44:36 sgallagh: no 18:44:43 nirik: no? 18:44:47 mass rebuild has to be several weeks before branch 18:44:51 #info change submission deadline in _less than two weeks_ 18:44:51 oh ok 18:45:02 otherwise we have to do rawhide and f22. and ... no thanks. ;) 18:45:12 mattdm: I'm going through right now and will send reminders soon 18:45:22 nirik: Several weeks? Or would one suffice? 18:45:22 jreznik: thanks1 18:45:25 remind me why we're going a mass rebuild? 18:45:28 I misspoke above; I meant a week before branch 18:45:50 jwb: Boost, if nothing else... 18:46:06 sgallagh: it's best to have several so things get cleaned up and fixed... 18:46:08 And don't we usually have a new gcc around then? 18:46:11 and yeah, we don't know yet 18:46:15 sgallagh: boost is in side tag 18:46:21 boost doesn't need mass rebuild. 18:46:24 ok 18:46:25 the PIE everything would. 18:46:28 new gcc would 18:46:29 yep 18:46:30 /me nods 18:46:45 Didn't we have the PIE everything discussion in F18 and decide against it? 18:46:46 nirik: the PIE should also use side tag, no? 18:46:51 so we're kind of doing this backwards 18:46:59 since we didn't actually approve or talk about those changes yet 18:47:07 thozza: not really, it would need every archfull package. 18:47:09 * jreznik does not see any need for any big changes in current draft before we get changes proposes (ala pie, probably gcc, other stuff) 18:47:10 yeah. 18:47:14 jwb: Well, "If we have to do a rebuild, it has to happen by this date" 18:47:16 sgallagh: I would also like to have that discussion again soonish FWIW. 18:47:20 We can ignore the hypotheticals 18:47:29 we can't decide mass rebuild until we decide all the changes 18:47:38 jwb: right, first talk about changes that could affect schedule before 18:48:03 nirik: If we didn’t do a mass rebuild, would we shorten the schedule? If not, let’s just schedule it now and we can drop it anytime. 18:48:26 Honestly, if we're trying to get back to a time-based schedule, I'd like us to say "If GCC isn't ready for a mass-rebuild by X, it waits until F23" 18:48:38 sgallagh, +1 18:48:57 also given the last record with major gcc update I am afraid of forced rebuilds. 18:49:01 we could... 18:49:11 if the update is done too hastily 18:49:16 sgallagh: +1 -- I do would do a schedule first and then see what features fit in there 18:49:21 how about 2015-01-29 18:49:26 sgallagh: +1 18:49:31 nirik: +1 18:49:32 The next gcc update is planned to change c++ ABI. 18:49:35 sgallagh: +1 18:49:42 sgallagh: and are we going back? I still hope we are not 18:49:54 mcatanzaro: Then *definitely* not a great idea for a short cycle 18:50:06 And enable c++11 unless explicitly disabled. 18:50:16 jreznik: I didn't understand the question 18:51:11 jreznik wants to go to a features-based schedule, I think? 18:51:12 sgallagh: going back to time based schedule, I still think the current compomise we have in between is the best way but it's up to fesco, I'lm just schedule wrangler :) 18:51:41 so what do we do if we say gcc isn't going to make the cut, and the maintainers don't buy in? 18:51:42 jreznik: well given that we still keep slipping multiple times ... I don't think it "worked" 18:51:47 mattdm: I think what we have now and we worked on for several years makes sense - draft schedule, take a look what we can do, finalize schedule 18:51:56 jreznik: I think the idea is to keep the compromise fundamentally, but tilt it more towards time-based? 18:52:06 jwb: Can we assume that they aren't going to be jerks (by default)? 18:52:20 drago01: That's a perception thing. Under the "current compromise", those slips are just part of the process, not a problem 18:52:35 drago01: and is that really bad thing? especially with fedora.next? where it had to be more feature driven than any other release 18:52:38 mattdm: not really 18:52:44 sgallagh, it's not a question of being a jerk. this is a community project. if there's an important package and the community member driving it doesn't agree, what do we do? 18:52:46 mattdm: exactly 18:52:47 jwb: also, if we have a schedule known in advance, the gcc folks are in a better position to decide if they should try to get a new gcc in or not 18:52:55 jwb: it's hard to do that without knowing the deadlines 18:53:00 mattdm: the slips after the schedule have been decided still happen 18:53:00 jwb: adjust schedule after that I guess? 18:53:04 jwb: I assume the maintainers won't want to ship a distro built on a prerelease gcc or force us to wait for them 18:53:06 mattdm: and those are sure not "by design" 18:53:18 drago01: no, they _are_ by design. That's the thing. 18:53:23 i'm not articulating my point well enough 18:53:29 Whether that's what we want to keep doing is... basically the question. 18:53:35 kalev: but we have draft now, if they think they really need latest gcc, let's talk about schedule implication - that's current compromise we're talking about 18:53:37 jwb: Welcome to my world :-/ 18:53:49 Is gcc the main thing we are concerned with at this point? 18:54:03 i was using it as an example. i wasn't really concerned 18:54:07 hard to say since we don't have all the proposed changes in hand. ;) 18:54:14 jreznik: yes it is ... it makes us look incomptenet 18:54:15 nirik, yes. 18:54:16 mattdm: s/gcc/any other significant piece of Fedora :) 18:54:30 jreznik: I mean, specifically. 18:54:37 drago01: again, that's a perception issue. 18:54:45 jreznik: we get lots of press like "slipped again" 18:54:46 (and I can't type= 18:54:46 drago01: and is that really problem? 18:54:46 ) 18:54:52 mattdm: I don't think there are plans to upgrade gcc this cycle, at least I haven't heard of them if there are 18:54:53 jreznik: "yes it is" 18:54:58 partly because we call them "slips". we could call them fluffy-good-times-bonus-weeks :) 18:55:00 no it isn' 18:55:02 no it isn't 18:55:07 * nirik notes there's several things being done to try and get rid of slips... is this the place to discuss them tho/ 18:55:10 mattdm, +1 :D 18:55:12 mattdm: does not make it not exist 18:55:12 it would be easier if we were proprietary company, I see much bigger changes here just it's not visible 18:55:28 happy new year! just like the old year so far! 18:55:36 let's get back to schedule 18:55:37 jwb: :D 18:55:40 jwb, +1 18:55:46 OK, let's ask the fundamental question first: 18:55:52 do we either wait to review changes, or go with the tentative schedule now? 18:55:55 mattdm: you can't just talk away issues and pretend they do not exit 18:56:06 So, annnyway, drago01, I basically agree with you and am just trying to explain the other viewpoint. 18:56:10 mattdm: exist ... that doesn't work 18:56:14 drago01, slips are inevitable 18:56:16 proposal: FESCo would like for F22 to strictly adhere to a schedule, rather than adjusting the schedule based on submitted features. 18:56:25 (Let's level-set, here) 18:56:35 drago01, and are not a really big problem unless they are indefinite 18:56:58 t8m: sure I am just saying the "new" processes has not make us slip any less ... so "going back" isn't any worse 18:57:05 sgallagh: +1 to that, I think it makes a lot of sense 18:57:06 (Note: I'm not attempting to answer the F23+ question above) 18:57:23 sgallagh: +0.5... that makes it sound like we wouldn't adjust ever, which seems too strong to me, but I am ok with setting the schedule 18:57:27 btw. this proposal of course does not mean no slips :) 18:57:32 sgallagh: I'm for it +1 18:57:41 sgallagh: to clarify, does this mean that there's going to be different procedures around qa and slips? 18:57:44 sgallagh, same as nirik 18:57:44 sgallagh: +0.5: schedule first, then features. 18:57:46 mattdm: no 18:57:48 nirik: I think it is better to sound like that to make them stick to the schedule 18:57:54 or are you just talking about the schedule strategy from _this_ point. 18:58:09 Just that we aren't going to say "Ok, with all these Changes, we're going to add two weeks to the schedule" 18:58:12 does this mean we REALLY require and stick to contingency plans for Changes? 18:58:12 thozza: OTOH lying lain doesn’t work. 18:58:18 Some Changes may be postponed instead. 18:58:19 ("this" = feature submissions) 18:58:26 okay. in that case, I am +1 18:58:34 jwb: We should, yes. 18:58:39 jwb: That would be my hope, yes 18:58:48 jwb: yes, it does and be strict - and as we know, sometimes it's even not possible at all 18:58:49 i'm only going to +1 this if everyone is on board with that. otherwise it's a toothless proposal 18:58:59 jwb: define "everyone".... 18:59:05 in fesco 18:59:14 jwb: +1 18:59:23 ok. I am on board. I've been saying it for a long time. 18:59:26 jreznik, no contingency plan means no for f22 is a good start. 18:59:28 jwb: what if the contingency plan is more work then just finishing the feature? (see f18 anaconda etc) 18:59:34 in the general sense +1 as I said 18:59:42 drago01, then it shouldn't have been accepted in the first place 18:59:47 drago01: make a better contingency plan, please? 18:59:48 also, let's stop talking about anaconda 18:59:49 drago01: Then we screwed up in approving it (and yes we do screw up) 18:59:50 jwb: Well, for System-Wide, I agree. For leaf projects... meh? 18:59:52 jwb: ok fair enough 19:00:03 drago01: yeah, anaconda is that example I'm talking about and it was the reason why we changed the way how we schedule :) 19:00:04 mitr: who doesn't? ;) 19:00:19 sgallagh: for those, "eh, we got this far" is usually an okay contingency 19:00:30 jreznik: it's done. movin' on. :) 19:00:34 anyway, +1 for being hardasses 19:00:38 jreznik: That was pretty exceptional. It's not going to change again in the immediate future. Let's stop basing decisions on a milestone we already passed. 19:00:49 /me starts doing squats. 19:00:50 sgallagh: self-contained changes already don’t have a mandatory contingency plan. 19:01:01 mitr: Right, I was just clarifying 19:01:07 sgallagh: I know it was one time and there are not so many examples as anaconda, fedora.next 19:01:27 so where are we here? 19:01:39 I think next we should finalize the current schedule? 19:01:46 Can we revote on my proposal? I lost track of it with all the ongoing stuff. 19:01:48 (jreznik: IIRC we did make a similar mistake since F18 at least once but I don't recall what it was.) 19:02:00 Are we agreed that we're going to tie down the schedule and be hardasses about contingency plans? 19:02:03 tell me to be real hardass, and I'll be, even personally I liked some kind of flexibility and making fedora better in the end (and I really don't think it will significantly change slips) 19:02:31 sgallagh: +1 sure. 19:02:37 sgallagh: +1 19:02:37 sgallagh: +1 19:02:41 sgallagh: +1 19:02:45 sgallagh: +1 19:02:59 we may want to wait for next week when dgilmore is back to set the side-tag and mass rebuild dates... not sure if he has anything in there that would affect them. 19:03:06 sgallagh, +1 19:03:09 nirik: That's fair. 19:03:22 nirik: yep 19:03:24 nirik: we maybe want to set tentative dates for those, so that Boost et al can schedule better 19:03:25 might be a short ramp for boost folks. 19:03:39 sgallagh: +1 ftr 19:04:19 #agreed FESCo would like for F22 to strictly adhere to a schedule, rather than adjusting the schedule based on submitted features. We intend to enforce the contingency plan very strictly this cycle (+8, 0, -0) 19:04:23 kalev: we could... say: 2015-01-29 for side tag merge, and 2015-01-30 for mass rebuild start? 19:04:40 (tenative) 19:04:45 nirik: Sounds good to me 19:04:52 nirik: maybe a few more days between the mass rebuild and merge? 19:05:05 there's usually fallout after a merge ... 19:05:14 kalev: could move to monday I suppose... feb 2nd 19:05:40 that doesn't leave much time after it before branch tho 19:05:54 or move tag merge earlier and leave mass rebuild on 2015-01-30 ? 19:05:54 nirik: That's also going to run into travel time for people headed to Brno 19:06:40 kalev: sure, but the meeting on the 28th would be our last one with proposed changes... I guess any change with a side tag then would be out of luck anyhow. 19:07:38 sgallagh, the project is large. maybe those people can find backups 19:07:52 because otherwise we suck terribly at scaling 19:07:54 Sure, just noting it. 19:08:14 nirik: I think 2 days between the merge and mass rebuild should be fine to get rawhide back in working order -- perhaps merge 2015-01-28 (same day as fesco meeting), and mass rebuild 2015-01-30 ? 19:08:16 (Mostly because both people that usually fire off mass rebuilds might be traveling at that time) 19:08:30 sgallagh, you're making my point for me. 19:08:39 You're welcome? 19:08:46 kalev: sure works for me for tenative. ;) 19:09:11 Anyone opposed, or shall I just #info that? 19:09:32 sgallagh, go ahead 19:09:55 #info Tentative date for side-tag merge is 2015-01-28 19:10:05 #info Tentative date for mass rebuild (if needed) is 2015-01-30 19:10:20 * jreznik will add it to the schedule 19:10:30 jreznik: Tentative date for side-tag merge is 2015-01-28 19:10:37 (In case you missed it) 19:10:43 ok 19:10:51 Do we need a more targeted announcement to the side-tag owners? 19:11:21 I think we need to make a devel-announce posting regarding the schedule in general (particularly the stricter contingency enforcement) 19:11:23 mitr: I can add it into the schedules reminder I'm going to send 19:11:40 sgallagh: that's of course going to be part of ^^^ 19:11:51 OK, I'll leave it to you, then 19:12:01 Just for a note I think we should probably move the Change submission and review process of Fn to be in parallel with the Fn-1 finalization. This is too tight deadline. 19:12:02 but tomorrow 19:12:05 #action jreznik to send schedule reminder announcement 19:12:11 but that's for F23 19:12:35 t8m: Usually it would be, but we were really close to the holidays with F21 19:12:42 And everyone was burned out 19:12:49 t8m: just f21 broke everything we do but for f22/f23 we will be in better situation 19:12:59 sgallagh was faster 19:13:00 t8m: We do accept change proposals much earlier (like we did discuss dnf for F22). 19:13:22 It’s just that they mostly arrive before the deadlines ☺ 19:13:27 and /me delayed it a bit too :( 19:13:50 mitr: that's another point, day before deadline is the right time to start writing change page :) 19:14:08 OK, so we didn't formally agree on the current schedule, but it sounds like we're good with it? 19:14:20 yes 19:14:22 sgallagh, +1 19:14:27 yep 19:14:29 * nirik nods 19:14:39 yes 19:14:57 yes 19:15:02 Yes 19:15:08 #agreed FESCo approves the current proposed schedule with a planned final delivery on 2015-05-19 (+8, 0, -0) 19:15:19 (including my implied +1) 19:15:56 Given the time, do we want to punt on the EOL and replacement tickets this week and get to the Changes? 19:16:08 yes 19:16:23 let's 19:16:40 well, for EOL - if you can comment in the ticket, would be great 19:16:46 #topic #1198 Possible changes to Fedora EOL bug procedure 19:16:46 #info FESCo punted on this until next meeting 19:16:47 #topic #1326 change to fesco replacement process? 19:16:47 #info FESCo punted on this until next meeting 19:16:48 especially that warning part 19:16:57 #topic #1378 F22 System Wide Change: Elasticsearch - https://fedoraproject.org/wiki/Changes/Elasticsearch 19:16:57 .fesco 1378 19:16:58 sgallagh: #1378 (F22 System Wide Change: Elasticsearch - https://fedoraproject.org/wiki/Changes/Elasticsearch) – FESCo - https://fedorahosted.org/fesco/ticket/1378 19:17:08 sgallagh, shouldn't there be FESCo elections just now? 19:17:18 so actually I'd prefer EOL first than changes 19:17:25 #undo 19:17:25 Removing item from minutes: 19:17:26 #undo 19:17:27 Removing item from minutes: INFO by sgallagh at 19:16:47 : FESCo punted on this until next meeting 19:17:27 t8m: it was my topic for open floor 19:17:28 #undo 19:17:28 Removing item from minutes: 19:17:31 #undo 19:17:31 Removing item from minutes: INFO by sgallagh at 19:16:46 : FESCo punted on this until next meeting 19:17:41 #undo 19:17:41 Removing item from minutes: 19:17:46 #topic #1198 Possible changes to Fedora EOL bug procedure 19:17:52 /me rewinds 19:18:01 okay so this is in progress 19:18:13 jreznik, I am ok with your proposal to the EOL bug procedure 19:18:15 to make it fast - due to my faulty brain, I messed warning part that should run before break 19:18:37 jreznik there was some mail from you when I was on vacation about the CLOSED:EOL name problem <- my fault 19:18:40 .fesco 1198 19:18:42 sgallagh: #1198 (Possible changes to Fedora EOL bug procedure) – FESCo - https://fedorahosted.org/fesco/ticket/1198 19:18:46 and we're already EOL - do we want to run short warning? or proceed with clossure? 19:18:51 mattdm: it's fixed now 19:18:58 so CLOSED:EOL is now fixed, it's EOL 19:18:59 jreznik: awesome thanks for taking care of that 19:19:10 do we have the changes in place which allow people to reopen? 19:19:30 other stuff like only selected user can use EOL resolution means coding on BZ side, they are looking on it 19:19:35 if we have the changes in place that allow reopening EOL tickets, I'd go directly to closing 19:19:48 jreznik: I never saw a reply to your thing about a group perm for EOL. Did that get sorted? 19:19:53 I don't think we have. 19:20:01 mattdm: that's what I'm not sure, would be nice to check 19:20:09 n.b. the plan is that the EOL tickets can be reopened but need to be changed to a newer version in the process 19:20:19 nirik: the answer from BZ team was that it probably needs some coding on BZ side 19:20:27 jreznik: ok. ;( 19:20:29 the person who said it would be no problem a year ago now has bouncing email so i assume has left rh 19:20:39 can we not test with partner-bugzilla? 19:21:05 nirik: we can probably test on some of victim bugs... there are many to try it :) 19:21:22 remainig respondants still seemed amenable to doing it, though. :) 19:21:37 proposal: send EOL warning now, wait until those scripts are in place to actually close 19:21:48 sure 19:21:58 I'm just thinking - if we remove F19 from the list of versions and someone reopens bug - what happens? is it still the same version or it forces it to the newer version? 19:22:05 well, partner-bugzilla has the advantage of not sending any emails. ;) 19:22:11 mattdm: yeah, that was my proposal 19:22:21 jreznik: we don't remove the version... they are all still there back to fc1. 19:22:29 nirik: I have flag in my script not to send mails (it's in XML RPM) 19:22:31 RPC 19:23:12 jreznik: you mean without additional scripting? I think it just leaves version same. 19:23:15 mattdm: for sending EOL warning - month period? to sort it out or shorter? 19:23:35 jreznik: You talked to the bugzilla people more recently. what do you think? 19:23:47 mattdm: should be easy to try it, I'll check tomorrow or anyone faster pls comment in ticket 19:24:00 (also, I kind of think not sending email defeats half the purpose.) 19:24:10 mattdm: just for testing... not the real thing 19:24:17 mattdm: not sending mails for testing only 19:24:18 nirik: ah okay good :) 19:24:34 or I can test on my own bugs 19:24:45 need to drop for one second. back shortly 19:25:06 mattdm: well, from all comments seems like it will need additional coding and I'm not sure we can get it anytime soon... 19:25:16 at least for EOL clossure 19:25:32 so let's go with month notice warning now, I can start tomorrow 19:25:38 jreznik: +1 19:25:40 and do some testing what's possible in current bz 19:25:46 * nirik thinks a month is a bit long. 19:25:56 jreznik, +1 19:25:57 Two weeks? 19:25:59 but I guess it doesn't matter too much... 19:26:06 f14/f15 was closed after several years :) 19:26:31 nirik: if some changes will be needed in bz, it's not too long 19:26:39 true... ok, a month it is then 19:26:53 for what it's worth, I personally just delete all the bugmail over the days of the EOL notices and hope that nothing important gets deleted along with the EOL spam 19:27:22 /me just applies a filter 19:27:37 kalev: percentage of people who really reacts is pretty low but maybe better than nothing 19:27:39 anyhow, move on now? 19:27:39 Anyway, ok. Send warning today, close in a month 19:27:47 sgallagh: yep 19:27:50 kalev: yeah, kind of painful for packagers with a lot of open bugs. +1 to filter. the emailed notice _hopefully_ gives users who care a reminder to retest. 19:27:57 and with mattdm we will follow up with bugzilla guys 19:28:14 #info F19 EOL warning will be sent today. We will auto-close all remaining bugs in one month. 19:28:23 #topic #1378 F22 System Wide Change: Elasticsearch - https://fedoraproject.org/wiki/Changes/Elasticsearch 19:28:23 .fesco 1378 19:28:24 sgallagh: #1378 (F22 System Wide Change: Elasticsearch - https://fedoraproject.org/wiki/Changes/Elasticsearch) – FESCo - https://fedorahosted.org/fesco/ticket/1378 19:28:31 +1 19:28:46 +1 19:29:02 +1 19:29:03 +1 19:29:12 I'm somewhat nervous about this, honestly. 19:29:19 +1, though a little worried whether everyone will be able to keep all of the packages in sync over time. 19:29:21 sgallagh: why? 19:29:49 The Change proposal is really vague. 19:30:05 Or rather, having _only_ ElasticSearch like this but having every package maintain manual bilateral keep-in-sync arrangements with every used dependency would be untenable. 19:30:38 Yeah that was the other part. There's basically no way we can hold Fedora packages on strict versions to support this. 19:30:50 Right, this is a prime example of the tradeoff we get with strict no-bundling policies. 19:31:01 mitr: yep, but it's about fine-tuning performance, so maybe it's not going to be that needed unless someone needs top performance (and it does not break stuff) 19:31:07 I'd rather reject this for F22 and have them work tightly with the Env/Stacks group for a better F23 plan. 19:31:10 Sadly? the practice of library$version packages has become very widespread so there is ample precedent that it is _possible_. 19:31:28 sgallagh: SCLs would be great for such change... 19:31:39 Sure... that's not going to happen for F22, last I checked. 19:31:44 sgallagh: that sounds reasonable 19:31:51 i +1'd this with the full expectation that we'd have to +1 some bundling exceptions for it 19:31:52 sgallagh: ISTM that the worst case is that one of the dependencies or users will lose a maintainer and the entire stack will be removed, which is IMHO not bad enough to reject the Change. 19:31:57 * nirik hopes that packaging it up in fedora would help upstream be better about the exacting versions stuff too 19:32:15 jwb: If that's an expectation, we should state it outright. 19:32:20 we can also allow bundling for some stuff if it's too painful to keep the versions in sync otherwise 19:32:22 ok. i just did :) 19:32:37 or SCLs might work 19:32:56 mitr: No, the worst case is that we can't upgrade to a newer version of one of the deps because Elasticsearch is holding it back. 19:33:02 kalev: I would not state it explicitly now 19:33:19 sgallagh: then if there is enough pressure, it can update and ES can make a compat package 19:33:28 jwb: so this would include a request to FPC to allow bundling exceptions for this package? 19:33:50 mattdm, if we think it's inevitable, yes. i was simply saying i expect it to happen, not that it will happen 19:33:59 sgallagh: and let's say that the new version fixes a security problem that there's no patch for in the old version... 19:34:17 * nirik doesn't know that it will happen, hard to say without closer looking at all the stuff involved or talking to the feature owner 19:34:19 mattdm: I know, this is an old argument. 19:34:23 mattdm: why do we want to approve it before it even happened? 19:34:28 then someone would have to do the usual dance of backporting the patch 19:34:34 on devel list, compat packages were mentioned and it should be easy for java packages... java guys says they have very good support and it's easy 19:34:57 jreznik, +1 19:34:59 I'm okay with approving it with a blanket exception to the bundling policy 19:35:03 jreznik: thanks -- I haven't caught up on devel list yet. That makes me feel better about it. 19:35:05 * nirik steps away for a min for more coffee. 19:35:10 Provided that FPC accepts that 19:35:20 (or accepts our authority to decide that, I should say) 19:35:23 sgallagh, I don't agree with such blanket exception 19:35:27 sgallagh: I’d much rather not have that blanket exception. Compat packages are better. 19:35:35 mitr, +1 19:35:41 mitr: +1 19:35:50 So should we ask for compat packages as the contingency plan? 19:35:55 (And they are a bigger hurdle to motivate people to keep with one version :) ) 19:36:16 mattdm: The contingency plan for F22 is very plausibly “not ship it”, that’s the easy part 19:36:29 i find compat packages to be amusing 19:36:56 they avoid "bundling" by making it possible so that everyone can share all the same CVEs that can't be fixed in that old version. 19:36:57 There's no contingency plan listed at all right now 19:37:23 sgallagh: right. and as per above, we should not approve this without one. 19:37:30 yes 19:37:43 change owner is going back in two weeks 19:37:57 jwb: They are clearly better than >1 bundled copy in that respect. No, they don’t ensure vulnerabilities get fixed. 19:37:59 going back? 19:38:00 oh, i missed that they didn't add a contingency plan. my mistake 19:38:29 and my mistake too not checking it properly 19:38:39 sgallagh: he's out for a few weeks 19:38:40 i'm changing my vote to a -1 19:38:40 There is some text in the contingency plan section, but it's basically _risks_, not fallback positions 19:39:01 well, fallback is easy - no elasticsearch 19:39:09 I'm going to stick with -1. As written, I don't want to accept this. 19:39:11 I could keep the +1 with assumption that the contingency is “package does not added”, but sending this back for a revision wouldn’t hurt that much. 19:39:25 same as mitr 19:39:27 mitr: yeah, I ask to fix it and resend 19:39:30 jreznik: Well, it may in fact have an effect on what versions of it deps we would ship. 19:39:49 +1 send back for revision. correction of a few typos (I assume that's not "rehat.com", right?) woudln't hurt either :) 19:40:03 I'd really rather see this fleshed our with the Env/Stacks group for a few months and re-proposed for F23 19:40:07 * jreznik already fixed a few typos there 19:40:27 So, send back for 1) contingency plan revision? or 2) completely change of approach? 19:40:35 (I am +1 -1 at the moment) 19:40:55 mitr: I'm +1 -1 too 19:40:55 elasticsearch is cool and it'd be _nice_ to have it, but, yeah. 19:40:56 sure, we should require a contingency plan... 19:41:03 mitr: +1 19:41:12 I don't see a COPR -- that would make a good proving ground. 19:41:24 mitr, I am +1 -1 as well 19:41:29 mattdm: yes, that would be great 19:41:30 I *really* want this to get used to solve the wider problem of "big packages with tight dep requirements". Hence why I want to make this an Env/Stacks problem. 19:41:49 It gives them a specific mission to accomplish, rather than generic solutions 19:42:05 them being who? 19:42:09 Env/Stacks? 19:42:11 jwb: Env/Stacks 19:42:22 I'm not sure what this wider solution would be... 19:42:34 seems like a good challenge for them, but i don't think it's fair to the Elastic packagers 19:42:37 I don't think we should take a Change for a hostage 19:42:41 and i don't see why it can't be done in parallel 19:42:49 jwb, +1 19:43:07 Because history shows that it won't be. ES will get whatever exceptions it needs and ignore Env/Stacks. 19:43:08 * nirik nods 19:43:12 yeah I agree with parallel, as long as there are people interested in actually working on parallel approaches. 19:43:33 sgallagh, if packagers can ignore a WG, they can ignore the FPC, FESCo, and pretty much anyway 19:43:36 right, all we know now is someone is willing to work on packaging it. 19:43:37 er, anyone 19:43:48 so it's up to us to give them incentive to work with Env/Stacks for an F23 solution 19:43:57 while not arbitrarily holding them up 19:44:14 and if that incentive is "if you ignore Env/Stacks, we punt your package", well... 19:44:28 they can always use COPR in the meanwhile 19:44:35 they could, this is true 19:44:48 I don't think threatening them is good... 19:44:56 So, as I read this, I think the change request is mostly a request for FESCo to ask the maintainers of the relevant dependencies to coordinate on versions. 19:44:59 thozza: yes but they don't need a Change for that at all and it won’t make the result a part of the distro. 19:45:01 I don't want to threaten them. 19:45:04 mattdm: yes 19:45:11 nirik, no, but assumign they're going to ignore Env/Stacks isn't good either. 19:45:15 Though I admit, it would probably come across that way 19:45:17 I think that's _fine_, but we'd like a better long-term framework for doing things like this in ways that scale. 19:45:22 * jreznik has to move to phone - ping me if needed... one topic for open floor - elections 19:45:23 mitr: that's why it is "in the meanwhile" 19:45:57 sgallagh: OTOH the combined constraints of (Env/Stacks + FPC) have so far made the possible solutions about zero, and FESCo telling others “wait for this zero-solution problem to be solved” would mostly add to the frustration without making a solutino more likely. 19:46:07 we could ask nicely for them to talk to env and stacks group and vice versa... but I don't think we should hold up packaging for it 19:46:20 nirik, +1 19:46:37 nirik: yes, I don't think we should hold up packaging for this either 19:47:30 My major concern is the potential for "locking" package versions. 19:47:45 mattdm: The right long-term framework is to only use, and only write, OS libraries with full ABI stability using symbol versioning and whatever other very-work-intensive solutions that requires. Without that there will be gazillions of versions and we will have no choice but to package them, and then _how_ we package them is a trivial issue compared to the workload necessary to package them in _any_ way 19:47:52 I don't believe (from this Change page) that the proposers have a sufficient plan in place for avoiding that. 19:48:11 sgallagh, so vote -1, tell them to address it in an update and resubmit 19:48:23 jwb: I thought I said that ten minutes ago... 19:48:26 yep. let's do that and move on to the next thing :) 19:48:30 then why are we still talking about this? 19:48:35 meeting fatigue is setting in 19:48:43 proposal: STOP TALKING ABOUT THIS 19:48:48 mattdm, it looks like that 19:48:56 i have to leave in like 3 minutes for good this time 19:49:04 So, to simplify: 19:49:16 Proposal: The approach is OK, please resubmit with a real contingency plan. 19:49:19 yes?no? 19:49:22 mitr, +1 19:49:22 I'm -1 on the grounds that there's no contingency plan and no clear mechanism for avoiding package locking. 19:49:23 * mitr is +1 19:49:29 mitr: +1 19:49:52 mitr: +1 19:50:01 mitr: +1 19:50:04 +1 i think 19:50:34 mattdm: ? 19:50:40 mitr: +1. If contingency plan involves new compat packages or similar, needs to specify who will actually do that 19:50:50 (For the record I would stop short of saying “this approach is recommended”, sgallagh does have valid concerns.) 19:51:03 #agreed Change is approved. The approach is OK, please resubmit with a real contingency plan. (+7, 0, -1) 19:51:28 #topic #1379 F22 System Wide Change: Change xorg input stack to use libinput - https://fedoraproject.org/wiki/Changes/LibinputForXorg 19:51:28 .fesco 1379 19:51:29 sgallagh: #1379 (F22 System Wide Change: Change xorg input stack to use libinput - https://fedoraproject.org/wiki/Changes/LibinputForXorg) – FESCo - https://fedorahosted.org/fesco/ticket/1379 19:51:35 2 concerns: 19:51:53 1) KKofler mentioned that KDE has a synaptics control panel; do we know who will take care of porting it? 19:52:29 2) The contingency plan says “switch back to old drivers”; I would just like to make sure that the updated/patched control panels will continue working 19:52:50 (/me apologizes for not raising 2) before, still recovering from a long PTO and email outage) 19:52:53 on 2... probibly need to add that those would have to be reverted too 19:53:59 Let's add 1) as a contingency-plan trigger (if either KDE or GNOME isn't fixed by contingency date, it goes into effect) 19:54:13 yeah, they are both release blocking. ;) 19:54:24 works for me 19:54:34 Right, but I want to make it clear that it's not up to KDE to play catch-up after contingency dare 19:54:36 *date 19:54:51 sgallagh, +1 19:54:57 works for me too, good idea to specify this 19:54:58 +1 19:55:09 +1 to that. It looks like the contingency plan is an easy switch back 19:56:12 +1 19:56:15 proposal: Approved with two caveats: 1) Both GNOME and KDE must be updated by the contingency date or it goes into effect and 2) the contingency plan should note that it will may reverting changes to the control panels as well. 19:56:25 sgallagh: +1 19:56:28 sgallagh: +1 19:56:33 +1 19:56:36 sgallagh: +1 19:56:41 sgallagh: +1 19:57:10 sgallagh, +1 19:57:46 #agreed Approved with two caveats: 1) Both GNOME and KDE must be updated by the contingency date or it goes into effect and 2) the contingency plan should note that it will may require reverting changes to the control panels as well. (+7, 0, -0) 19:57:57 (I assumed that nirik's +1 carried over. Correct me if I'm mistaken) 19:58:00 yeah, +1 19:58:15 Last one: 19:58:16 #topic #1380 F22 System Wide Change: wxPython 3 - https://fedoraproject.org/wiki/Changes/wxPython3 19:58:17 .fesco 1380 19:58:18 sgallagh: #1380 (F22 System Wide Change: wxPython 3 - https://fedoraproject.org/wiki/Changes/wxPython3) – FESCo - https://fedorahosted.org/fesco/ticket/1380 19:58:22 +1 19:58:27 +1 19:58:47 +1 19:58:50 +1 19:58:55 +1 19:58:57 +1 19:59:06 Though I question why they have a separate contingency deadline... 19:59:21 Beta freeze is probably too late. 19:59:48 oh geez i used to maintain this package and I'm glad someone else does now :) 19:59:48 sgallagh, +1 20:00:28 Addendum to the acceptance: must meet the same contingency date as everything else? 20:00:43 sgallagh: +1 to that addendum 20:00:51 sgallagh: +1 20:00:56 +1 20:00:57 I'm -1 overall otherwise. 20:01:12 +1 to that... 20:01:52 sgallagh: What do you mean by "separate" deadline? Beta freeze is the standard one. 20:02:21 mitr: "2015-02-24: Change Checkpoint: Completion deadline (testable)" 20:02:51 I mean that any dependent rebuilds need to be done by Alpha. 20:02:58 Bugs can be fixed until Beta before reverting. 20:03:07 sgallagh, +1 to the addendum 20:03:20 sgallagh: but contengency deadline is “When is the last time the contingency mechanism can be put in place?” 20:03:30 That change checkpoint still applies 20:03:30 Good point. 20:03:39 Sorry, getting tired. 20:03:47 My addendum is therefore completely redundant. 20:03:47 (Though, to be fair, I was equally confused and thinking the same thing as you about what the deadline means.) 20:04:30 meeting fatigue strikes again! 20:04:45 #agreed Change is approved. (+7, 0, -0) 20:04:53 #topic Next week's chair 20:05:01 /me tosses the grenade 20:05:10 Who's going to fall on it this week? 20:05:23 Btw elections should start soon 20:05:38 jreznik_pp: -> next open floor topic? 20:05:47 * mattdm looks around shifty-eyed 20:05:59 okay fine I'll do it :) 20:06:14 #info mattdm to chair next week's meeting 20:06:18 Oops, sorry, I saw grenade on this meeting, not chair, heh 20:06:19 #topic Elections 20:06:33 Draft is on elections page 20:06:39 link? 20:06:47 I'm on phone 20:07:08 http://fedoraproject.org/wiki/Elections 20:07:12 #link https://fedoraproject.org/wiki/Elections 20:07:48 No FAmSCo this time but env and stacks 20:08:07 Mattdm, pls take a look 20:08:16 seems fine to me 20:08:22 * mattdm looking 20:08:35 We will need announcement ;-) 20:08:40 Sounds good to me 20:08:46 yeah looks good to me too 20:08:56 jreznik_pp: you want annoucnement from me or you wanna do it? 20:09:16 I don't mind doing it 20:09:39 jreznik_pp: help yourself :) 20:09:50 I can help with Fedora Magazine again. 20:10:02 Ok 20:10:14 We will sync over next few days 20:10:21 FTR I don't plan to run again. It's been fun. :) 20:10:43 All from me today 20:10:55 Time to get off the bus 20:11:17 Any opposition to the proposed election schedule? 20:11:20 mattdm: it's like you're busy with other stuff or something. ;) 20:11:40 sgallagh, no 20:11:57 #info Elections will open for nominations on January 13th. Voting will open on January 27th. 20:12:03 #topic Open Floor 20:12:57 Anything, or are we all well and truly out-meetinged? 20:13:03 * mattdm falls over 20:13:14 completely 20:13:26 end it :) 20:13:27 Thanks for sticking it out this far, folks 20:13:30 #endmeeting