18:01:22 <sgallagh> #startmeeting FESCO (2015-01-07)
18:01:22 <zodbot> 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 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:01:22 <sgallagh> #meetingname fesco
18:01:22 <zodbot> The meeting name has been set to 'fesco'
18:01:22 <sgallagh> #chair dgilmore jwb kalev mattdm mitr mmaslano nirik sgallagh stickster t8m thozza
18:01:22 <sgallagh> #topic init process
18:01:22 <zodbot> Current chairs: dgilmore jwb kalev mattdm mitr mmaslano nirik sgallagh stickster t8m thozza
18:01:30 <t8m> hi all
18:01:31 <nirik> morning everyone.
18:01:37 <jwb> hi
18:01:38 <kalev> hello
18:01:39 * mattdm crawls out from cave, blinks in sunlight
18:01:43 <thozza> 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 <sgallagh> .hello sgallagh
18:01:58 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
18:02:11 <mattdm> .hello mattdm
18:02:13 <zodbot> mattdm: mattdm 'Matthew Miller' <mattdm@mattdm.org>
18:02:19 <mitr> Hello
18:02:24 <hadess> hey
18:03:17 <twoerner> hello
18:03:38 * jreznik is around, on the team meeting - ping me when you'll need me
18:04:22 <sgallagh> OK, that looks like almost everyone, so we can just get started
18:04:36 <sgallagh> #topic #1372 "Workstation" Product defaults to wide-open firewall
18:04:36 <sgallagh> .fesco 1372
18:04:37 <zodbot> sgallagh: #1372 ("Workstation" Product defaults to wide-open firewall) – FESCo - https://fedorahosted.org/fesco/ticket/1372
18:05:16 <mattdm> are the various stakeholders in attendence?
18:05:30 <sgallagh> I saw twoerner. I haven't seen Bastien.
18:05:56 <jwb> sgallagh, hadess is here
18:06:02 <hadess> sgallagh, you're not looking hard enough :)
18:06:14 <t8m> I am afraid there is no solution that is acceptable to everyone.
18:06:20 <sgallagh> Ah, I didn't realize that nick matched that name
18:07:13 <sgallagh> So, before we start arguing about solutions (short- and long-term), I was hoping we could discuss goals
18:07:31 <sgallagh> I don't think anyone is perfectly happy with the current state (is that a fair statement?)
18:07:51 <mattdm> fair understatement, maybe even
18:08:01 <nirik> I'm not sure we need to discuss solutions here tho...
18:08:10 <t8m> nirik, +1
18:08:15 <nirik> unless we feel that it's worth overriding the workstation working group.
18:08:20 <mitr> 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 <nirik> which IMHO, I am -1 to
18:08:25 <sgallagh> nirik: Well, we need to try to agree on an end-experience, not necessarily an implementation
18:08:38 <t8m> mitr, +1
18:08:41 <hadess> the long term goals were mentioned in my mail to fedora workstation, definitely not finished, but certainly on the right path
18:08:52 <nirik> sgallagh: we do? isn't that for the workstation working group?
18:08:53 <sgallagh> I'm not explaining myself well enough
18:09:02 <jwb> please explain more.
18:10:22 <sgallagh> /me tries to find appropriate phrasing
18:11:52 <sgallagh> 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 <jwb> i disagree.
18:12:42 <jwb> 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 <hadess> 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 <sgallagh> Well, the guidance we gave was "have the firewall and desktop people talk it out and come to a decision"
18:13:32 <nirik> 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 <jwb> and that decision was made
18:13:33 <kalev> that seemed to work pretty well, I should point out
18:13:37 <sgallagh> The communication kind of failed and both groups came away from the discussion with a different understanding of what was decided
18:13:39 <t8m> jwb, didn't it actually give at least vague guidance that the firewall should be there
18:13:46 <jwb> t8m, no
18:13:55 <mattdm> jwb: actually yes, at least partially
18:14:08 <t8m> jwb, i have to disagree
18:14:11 <hadess> sgallagh, it didn't fail, no
18:14:17 <mattdm> the proposal was "no firewall at all" and fesco voted against that
18:14:18 <twoerner> hadess: I do not agree
18:14:28 <jwb> t8m, mattdm: and the existing solution has a firewall
18:14:41 <sgallagh> 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 <t8m> jwb, i am not saying it does not
18:14:45 <mitr> 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 <hadess> twoerner, you don't agree, but mitr did, he hopefully still does
18:14:50 <nirik> twoerner: could you share what you would like to see here?
18:15:11 <hadess> sgallagh, the problem seems to have been that i talked to one person not two, and they don't agree
18:15:21 <mitr> sgallagh, hadess: For context, I am not a “firewalld developer”.
18:15:47 <sgallagh> hadess: That would qualify as a communication failure. Not necessarily anyone's direct *fault*.
18:16:33 <sgallagh> 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 <mclasen> failure to reach an agreement on every detail is not a communication failure. Sometimes, people just disagree
18:17:08 <mitr> 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 <sgallagh> mclasen: Failure to talk to the right people is a communication failure.
18:17:39 <mclasen> who decides who the right people are ?
18:17:41 <jwb> let's focus on moving on, and not the definition of communication
18:17:47 <hadess> mitr, you've seen how it ended up on devel@, i'm completely happy with that decision :)
18:17:49 <sgallagh> jwb: yes
18:17:51 <jwb> so what do you want to actually accomplish here?
18:17:54 <t8m> jwb, +1
18:18:09 <mitr> 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 <sgallagh> 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 <nirik> sgallagh: I don't think anyone says this is immutable.
18:18:56 <kalev> twoerner: what's the problem with current setup?
18:18:59 <mitr> Primarily, kkofler raised this.
18:19:24 <twoerner> nirik: I voted against the use of the current workstation zone
18:19:35 <t8m> I believe it is mainly about expectations.
18:19:50 <nirik> 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 <sgallagh> 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 <twoerner> kalev: that the ports above 1024 are completely open
18:20:26 <sgallagh> And documenting well how to use them
18:20:28 <nirik> 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 <nirik> mclasen: no no, we need a popup!
18:20:56 <sgallagh> mclasen: No, we've been over that before. That's the wrong answer.
18:20:58 <mitr> sgallagh: Where “firewall configuration” is what?  A package?  A command to type?
18:21:06 <sgallagh> But a simple Firewall selection in GNOME Settings?
18:21:07 <mitr> Because we seem to have that command :)
18:21:08 <sgallagh> Maybe
18:21:08 <t8m> 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 <twoerner> so that for example databases are reachable for everyone, which is bad on a (web-)development machine
18:21:16 <nirik> sgallagh: we have that.
18:21:22 <t8m> If there...
18:21:33 <hadess> sgallagh, there's already a "paranoid" setting available from the UI, though the default zone cannot be changed in the UI
18:21:58 <mattdm> twoerner: meh. I don't care if a database server is reachable for everyone on my home network.
18:22:04 <nirik> twoerner: which the user installed and setup... so, it's the expectation you are objecting to?
18:22:14 <mitr> 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 <twoerner> nirik: there was a nice proposal for a layer in the desktop
18:22:25 <thozza> which applications needs ports >1024 to be open to work properly?
18:22:26 <hadess> twoerner, it was awful UI
18:22:47 <nirik> layer?
18:22:48 <mclasen> firewallds configuration is just not ready for a ui
18:22:49 <twoerner> mattdm: I agree for @home.. but the workstation zone is also used for public (open) wifis by default
18:22:49 <t8m> mitr, I think it is more a publicity problem than a real security problem :)
18:22:53 <sgallagh> OK, we shouldn't get into the details here.
18:23:04 <hadess> thozza, they're listed over and over again in the thread, at least half-a-dozen applications in the default install
18:23:05 <mattdm> sgallagh++
18:23:07 <twoerner> going to a internet cafe is bad with this
18:23:16 <sgallagh> 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 <nirik> 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 <hadess> twoerner, not any more than it was before, really
18:24:25 <mcatanzaro> 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 <mattdm> 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 <drago01> twoerner: which database listens on all interfaces by default?
18:24:55 <drago01> twoerner: that sounds like a bad practice regardless of firefwall presense
18:25:01 <jwb> apologies for dropping off.  i had a power outage here
18:25:06 <jwb> win 14
18:25:09 <twoerner> mcatanzaro: should? which service is doing this?
18:25:35 <mcatanzaro> hadess, gnome-settings-daemon? (?)
18:25:45 <twoerner> drago01: yes it is
18:26:01 <hadess> 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 <twoerner> mcatanzaro: so all database services are using gnome-settings-daemon??
18:26:48 <twoerner> mcatanzaro: as Workstation is meant for developers there is more than gnome-*
18:26:51 <mitr> 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, 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 <mattdm> mitr: I'm thinking more like: having fewer zones, and having zone selection more discoverable from the gnome/networkmanager ui
18:27:56 <drago01> twoerner: ok so which db does that?
18:28:26 <t8m> drago01, any random third party db
18:28:29 <jwb> so i take it we've moved from "let the Workstation WG discuss/decide this" to "FESCo needs to discuss implementations"?
18:28:37 <nirik> apparently
18:28:46 <drago01> t8m: oh so you don't mean the ones we ship ok
18:28:48 <jwb> amazing how quickly that happened.  the power was only out for about 2 min here
18:28:48 <hadess> mattdm, i already explained that zones aren't a good match for something user visible
18:28:53 <mattdm> jwb you're right; can we pull this back?
18:29:02 <t8m> 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 <sgallagh> 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 <mitr> 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 <nirik> not sure how that helps us, until the neural brain plug interface happens so we know what the user intends. ;)
18:30:17 <sgallagh> 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 <sgallagh> There's got to be a sensible middle-ground
18:30:42 <t8m> sgallagh, really?
18:30:46 <hadess> 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 <t8m> sgallagh, I don't actually believe much in that.
18:31:24 <nirik> proposal: close ticket, ask interested parties to continue to work with the workstation group to improve things.
18:31:37 <t8m> nirik, +1
18:31:38 <sgallagh> nirik: We just had people stating that they don't think they can
18:31:46 <sgallagh> s/people/the relevant people/
18:32:07 <mitr> 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 <kalev> nirik: +1
18:32:13 <nirik> sgallagh: which is too bad, but you can't make everyone agree all the time.
18:32:23 <t8m> well maybe we could also somehow approve (or disapprove) the current situation as acceptable (or inacceptable)
18:32:36 <kalev> 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 <mitr> 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 <nirik> mitr: the workstation working group did not file this ticket.
18:33:08 <mitr> 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 <nirik> it was a user trying to override them
18:33:24 <mitr> nirik: True; I believe the outcome would follow.
18:33:42 <hadess> mitr, 2) was planned for f21, but taskotron never got to the point where it was usable for this purpose
18:33:46 <mitr> Proposal 3) Find someone interested in editing the release notes or otherwise highlighting this defaults change for long-term users.
18:33:49 <mattdm> nirik: they filed the original change request
18:33:55 <hadess> mitr, i doubt it is now
18:33:56 <sgallagh> mitr: Why does "following our established guidelines" have to be automated here?
18:34:01 <mitr> hadess: IMHO that should have been a _blocker_ for making that config change for F21.  A Blocker means a blocker.
18:34:21 <nirik> 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 <mitr> sgallagh: What is this in reference to?
18:34:33 <sgallagh> "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 <mattdm> nirik +1
18:34:46 <hadess> mitr, given that i can't strongarm people into working on taskotron faster, that means pushing it back indefinitely
18:34:58 <sgallagh> We already have that stated explicitly that nothing can listen (externally) by default without permission
18:35:02 <mitr> 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 <nirik> mitr: if you can get QA buyin for such work, ok... but that sounds like a unfunded mandate. ;)
18:35:08 <jwb> we have 4 different proposals
18:35:15 <jwb> this is kind of a trainwreck
18:35:24 <sgallagh> mitr: Well, forcing the firewall to work around process failures is a bad idea
18:35:32 <mclasen> everything we do in fedora is unfunded...sad reality
18:35:58 <sgallagh> OK, let's take this back to the very top-level.
18:36:05 <mitr> hadess: No, that would mean pushing other Workstation work back.
18:36:27 <sgallagh> 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 <hadess> mitr, there's no one in workstation qualified to do that
18:36:31 <mitr> (Noting that 1) would make 2)3) obsolete)
18:36:43 <hadess> mitr, presumably there's nobody in your team to work on it either
18:37:13 <nirik> sgallagh: +1
18:37:17 <mitr> 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 <jwb> sgallagh, +1
18:37:28 <t8m> mitr, +1
18:37:30 <sgallagh> (For the record, I am +1 to my own proposal)
18:37:35 <kalev> sgallagh: +1
18:37:48 <mattdm> sgallagh: +1
18:37:57 <hadess> mitr, so tell me why the security folks aren't the ones working on that?
18:38:00 <t8m> sgallagh, this is equivalent to mitr's proposal 1)
18:38:01 <sgallagh> (I also volunteer my own time to the Workstation WG if they want to consult me for input)
18:38:07 <thozza> sgallagh: We see they didn't do that, so what guarantees that they will?
18:38:14 <mitr> sgallagh: I’m not so sure.  I _am_ fairly happy with the status quo but #1301 really wasn't trust-inspiring.
18:38:33 <mitr> sgallagh: (it passed anyway so just for the record.)
18:38:35 <t8m> sgallagh, +0
18:38:40 <mitr> sgallagh: +0 I guess.
18:38:47 <thozza> +0, too
18:38:49 <mcatanzaro> mitr: Safe bet that the status quo will prevail, at least in the mid-term.
18:39:25 <sgallagh> I've got (+5, 3, -0).
18:39:32 <mitr> 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 <thozza> sgallagh: one vote from t8m was for mitr
18:40:04 <sgallagh> #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 <sgallagh> thozza: I know; I counted him as +0
18:40:12 <t8m> thozza, he voted for himself, it is correctly counted
18:40:18 <thozza> ahh, ok
18:41:07 <sgallagh> #info sgallagh volunteers to act as a security consultant to the Workstation team if they are interested.
18:41:13 <sgallagh> #topic #1349 Fedora 22 scheduling strategy (and beyond)
18:41:13 <sgallagh> .fesco 1349
18:41:15 <zodbot> sgallagh: #1349 (Fedora 22 scheduling strategy (and beyond)) – FESCo - https://fedorahosted.org/fesco/ticket/1349
18:41:20 <hadess> mitr, working on regression testing server packages that go in fedora should be
18:42:04 <sgallagh> So... we've left this decision long enough, yes?
18:42:15 <kalev> we have a very rough schedule at http://fedoraproject.org/wiki/Releases/22/Schedule
18:42:17 <nirik> FWIW, I found one thing listening on my laptop >1024. unbound-control. Guess I should file a bug on it.
18:43:17 <sgallagh> I'm fairly comfortable with the proposed schedule.
18:43:28 <jwb> i think it's as good as it's going to get for now
18:43:30 <thozza> nirik: if on all interfaces, we should change it
18:43:31 <nirik> seems fine to me.
18:43:38 <sgallagh> 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 <mattdm> #link http://fedoraproject.org/wiki/Releases/22/Schedule
18:44:13 <nirik> oh, it is localhost. nevermind. ;)
18:44:21 <mattdm> so, that means change submission deadline in _less than two weeks_
18:44:24 <sgallagh> I'd suggest that we schedule the mass rebuild for seven days before Alpha freeze
18:44:35 <jreznik> mattdm: yes
18:44:35 <sgallagh> jreznik: ping (this is likely important to you)
18:44:36 <nirik> sgallagh: no
18:44:43 <sgallagh> nirik: no?
18:44:47 <nirik> mass rebuild has to be several weeks before branch
18:44:51 <mattdm> #info change submission deadline in _less than two weeks_
18:44:51 <sgallagh> oh ok
18:45:02 <nirik> otherwise we have to do rawhide and f22. and ... no thanks. ;)
18:45:12 <jreznik> mattdm: I'm going through right now and will send reminders soon
18:45:22 <sgallagh> nirik: Several weeks? Or would one suffice?
18:45:22 <mattdm> jreznik: thanks1
18:45:25 <jwb> remind me why we're going a mass rebuild?
18:45:28 <sgallagh> I misspoke above; I meant a week before branch
18:45:50 <sgallagh> jwb: Boost, if nothing else...
18:46:06 <nirik> sgallagh: it's best to have several so things get cleaned up and fixed...
18:46:08 <sgallagh> And don't we usually have a new gcc around then?
18:46:11 <nirik> and yeah, we don't know yet
18:46:15 <jreznik> sgallagh: boost is in side tag
18:46:21 <nirik> boost doesn't need mass rebuild.
18:46:24 <sgallagh> ok
18:46:25 <nirik> the PIE everything would.
18:46:28 <nirik> new gcc would
18:46:29 <jreznik> yep
18:46:30 <sgallagh> /me nods
18:46:45 <sgallagh> Didn't we have the PIE everything discussion in F18 and decide against it?
18:46:46 <thozza> nirik: the PIE should also use side tag, no?
18:46:51 <jwb> so we're kind of doing this backwards
18:46:59 <jwb> since we didn't actually approve or talk about those changes yet
18:47:07 <nirik> 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 <nirik> yeah.
18:47:14 <sgallagh> jwb: Well, "If we have to do a rebuild, it has to happen by this date"
18:47:16 <mitr> sgallagh: I would also like to have that discussion again soonish FWIW.
18:47:20 <sgallagh> We can ignore the hypotheticals
18:47:29 <nirik> we can't decide mass rebuild until we decide all the changes
18:47:38 <jreznik> jwb: right, first talk about changes that could affect schedule before
18:48:03 <mitr> 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 <sgallagh> 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 <t8m> sgallagh, +1
18:48:57 <t8m> also given the last record with major gcc update I am afraid of forced rebuilds.
18:49:01 <nirik> we could...
18:49:11 <t8m> if the update is done too hastily
18:49:16 <kalev> sgallagh: +1 -- I do would do a schedule first and then see what features fit in there
18:49:21 <nirik> how about 2015-01-29
18:49:26 <thozza> sgallagh: +1
18:49:31 <sgallagh> nirik: +1
18:49:32 <mcatanzaro> The next gcc update is planned to change c++ ABI.
18:49:35 <mitr> sgallagh: +1
18:49:42 <jreznik> sgallagh: and are we going back? I still hope we are not
18:49:54 <sgallagh> mcatanzaro: Then *definitely* not a great idea for a short cycle
18:50:06 <mcatanzaro> And enable c++11 unless explicitly disabled.
18:50:16 <sgallagh> jreznik: I didn't understand the question
18:51:11 <mattdm> jreznik wants to go to a features-based schedule, I think?
18:51:12 <jreznik> 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 <jwb> 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 <drago01> jreznik: well given that we still keep slipping multiple times ... I don't think it "worked"
18:51:47 <jreznik> 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 <mattdm> jreznik: I think the idea is to keep the compromise fundamentally, but tilt it more towards time-based?
18:52:06 <sgallagh> jwb: Can we assume that they aren't going to be jerks (by default)?
18:52:20 <mattdm> drago01: That's a perception thing. Under the "current compromise", those slips are just part of the process, not a problem
18:52:35 <jreznik> 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 <drago01> mattdm: not really
18:52:44 <jwb> 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 <jreznik> mattdm: exactly
18:52:47 <kalev> 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 <kalev> jwb: it's hard to do that without knowing the deadlines
18:53:00 <drago01> mattdm: the slips after the schedule have been decided still happen
18:53:00 <nirik> jwb: adjust schedule after that I guess?
18:53:04 <sgallagh> 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 <drago01> mattdm: and those are sure not "by design"
18:53:18 <mattdm> drago01: no, they _are_ by design. That's the thing.
18:53:23 <jwb> i'm not articulating my point well enough
18:53:29 <mattdm> Whether that's what we want to keep doing is... basically the question.
18:53:35 <jreznik> 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 <sgallagh> jwb: Welcome to my world :-/
18:53:49 <mattdm> Is gcc the main thing we are concerned with at this point?
18:54:03 <jwb> i was using it as an example.  i wasn't really concerned
18:54:07 <nirik> hard to say since we don't have all the proposed changes in hand. ;)
18:54:14 <drago01> jreznik: yes it is ... it makes us look incomptenet
18:54:15 <jwb> nirik, yes.
18:54:16 <jreznik> mattdm: s/gcc/any other significant piece of Fedora :)
18:54:30 <mattdm> jreznik: I mean, specifically.
18:54:37 <mattdm> drago01: again, that's a perception issue.
18:54:45 <drago01> jreznik: we get lots of press like "slipped again"
18:54:46 <drago01> (and I can't type=
18:54:46 <jreznik> drago01: and is that really problem?
18:54:46 <drago01> )
18:54:52 <kalev> 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 <drago01> jreznik: "yes it is"
18:54:58 <mattdm> partly because we call them "slips". we could call them fluffy-good-times-bonus-weeks :)
18:55:00 <t8m> no it isn'
18:55:02 <t8m> 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 <t8m> mattdm, +1 :D
18:55:12 <drago01> mattdm: does not make it not exist
18:55:12 <jreznik> it would be easier if we were proprietary company, I see much bigger changes here just it's not visible
18:55:28 <jwb> happy new year!  just like the old year so far!
18:55:36 <jwb> let's get back to schedule
18:55:37 <jreznik> jwb: :D
18:55:40 <t8m> jwb, +1
18:55:46 <sgallagh> OK, let's ask the fundamental question first:
18:55:52 <jwb> do we either wait to review changes, or go with the tentative schedule now?
18:55:55 <drago01> mattdm: you can't just talk away issues and pretend they do not exit
18:56:06 <mattdm> So, annnyway, drago01, I basically agree with you and am just trying to explain the other viewpoint.
18:56:10 <drago01> mattdm: exist ... that doesn't work
18:56:14 <t8m> drago01, slips are inevitable
18:56:16 <sgallagh> proposal: FESCo would like for F22 to strictly adhere to a schedule, rather than adjusting the schedule based on submitted features.
18:56:25 <sgallagh> (Let's level-set, here)
18:56:35 <t8m> drago01, and are not a really big problem unless they are indefinite
18:56:58 <drago01> 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 <kalev> sgallagh: +1 to that, I think it makes a lot of sense
18:57:06 <sgallagh> (Note: I'm not attempting to answer the F23+ question above)
18:57:23 <nirik> 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 <jreznik> btw. this proposal of course does not mean no slips :)
18:57:32 <thozza> sgallagh: I'm for it +1
18:57:41 <mattdm> sgallagh: to clarify, does this mean that there's going to be different procedures around qa and slips?
18:57:44 <t8m> sgallagh, same as nirik
18:57:44 <mitr> sgallagh: +0.5: schedule first, then features.
18:57:46 <sgallagh> mattdm: no
18:57:48 <thozza> nirik: I think it is better to sound like that to make them stick to the schedule
18:57:54 <mattdm> or are you just talking about the schedule strategy from _this_ point.
18:58:09 <sgallagh> 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 <jwb> does this mean we REALLY require and stick to contingency plans for Changes?
18:58:12 <mitr> thozza: OTOH lying lain doesn’t work.
18:58:18 <sgallagh> Some Changes may be postponed instead.
18:58:19 <mattdm> ("this" = feature submissions)
18:58:26 <mattdm> okay. in that case, I am +1
18:58:34 <mitr> jwb: We should, yes.
18:58:39 <sgallagh> jwb: That would be my hope, yes
18:58:48 <jreznik> jwb: yes, it does and be strict - and as we know, sometimes it's even not possible at all
18:58:49 <jwb> i'm only going to +1 this if everyone is on board with that.  otherwise it's a toothless proposal
18:58:59 <mattdm> jwb: define "everyone"....
18:59:05 <jwb> in fesco
18:59:14 <sgallagh> jwb: +1
18:59:23 <mattdm> ok. I am on board. I've been saying it for a long time.
18:59:26 <jwb> jreznik, no contingency plan means no for f22 is a good start.
18:59:28 <drago01> jwb: what if the contingency plan is more work then just finishing the feature? (see f18 anaconda etc)
18:59:34 <t8m> in the general sense +1 as I said
18:59:42 <jwb> drago01, then it shouldn't have been accepted in the first place
18:59:47 <mattdm> drago01: make a better contingency plan, please?
18:59:48 <jwb> also, let's stop talking about anaconda
18:59:49 <mitr> drago01: Then we screwed up in approving it (and yes we do screw up)
18:59:50 <sgallagh> jwb: Well, for System-Wide, I agree. For leaf projects... meh?
18:59:52 <drago01> jwb: ok fair enough
19:00:03 <jreznik> 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 <drago01> mitr: who doesn't? ;)
19:00:19 <mattdm> sgallagh: for those, "eh, we got this far" is usually an okay contingency
19:00:30 <mattdm> jreznik: it's done. movin' on. :)
19:00:34 <jwb> anyway, +1 for being hardasses
19:00:38 <sgallagh> 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 <sgallagh> /me starts doing squats.
19:00:50 <mitr> sgallagh: self-contained changes already don’t have a mandatory contingency plan.
19:01:01 <sgallagh> mitr: Right, I was just clarifying
19:01:07 <jreznik> sgallagh: I know it was one time and there are not so many examples as anaconda, fedora.next
19:01:27 <nirik> so where are we here?
19:01:39 <kalev> I think next we should finalize the current schedule?
19:01:46 <sgallagh> Can we revote on my proposal? I lost track of it with all the ongoing stuff.
19:01:48 <mitr> (jreznik: IIRC we did make a similar mistake since F18 at least once but I don't recall what it was.)
19:02:00 <sgallagh> Are we agreed that we're going to tie down the schedule and be hardasses about contingency plans?
19:02:03 <jreznik> 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 <nirik> sgallagh: +1 sure.
19:02:37 <kalev> sgallagh: +1
19:02:37 <thozza> sgallagh: +1
19:02:41 <sgallagh> sgallagh: +1
19:02:45 <mitr> sgallagh: +1
19:02:59 <nirik> 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 <t8m> sgallagh, +1
19:03:09 <sgallagh> nirik: That's fair.
19:03:22 <jreznik> nirik: yep
19:03:24 <kalev> nirik: we maybe want to set tentative dates for those, so that Boost et al can schedule better
19:03:25 <nirik> might be a short ramp for boost folks.
19:03:39 <mattdm> sgallagh: +1 ftr
19:04:19 <sgallagh> #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 <nirik> kalev: we could... say: 2015-01-29 for side tag merge, and 2015-01-30 for mass rebuild start?
19:04:40 <nirik> (tenative)
19:04:45 <sgallagh> nirik: Sounds good to me
19:04:52 <kalev> nirik: maybe a few more days between the mass rebuild and merge?
19:05:05 <kalev> there's usually fallout after a merge ...
19:05:14 <nirik> kalev: could move to monday I suppose... feb 2nd
19:05:40 <nirik> that doesn't leave much time after it before branch tho
19:05:54 <kalev> or move tag merge earlier and leave mass rebuild on 2015-01-30 ?
19:05:54 <sgallagh> nirik: That's also going to run into travel time for people headed to Brno
19:06:40 <nirik> 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 <jwb> sgallagh, the project is large.  maybe those people can find backups
19:07:52 <jwb> because otherwise we suck terribly at scaling
19:07:54 <sgallagh> Sure, just noting it.
19:08:14 <kalev> 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 <sgallagh> (Mostly because both people that usually fire off mass rebuilds might be traveling at that time)
19:08:30 <jwb> sgallagh, you're making my point for me.
19:08:39 <sgallagh> You're welcome?
19:08:46 <nirik> kalev: sure works for me for tenative. ;)
19:09:11 <sgallagh> Anyone opposed, or shall I just #info that?
19:09:32 <t8m> sgallagh, go ahead
19:09:55 <sgallagh> #info Tentative date for side-tag merge is 2015-01-28
19:10:05 <sgallagh> #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 <sgallagh> jreznik: Tentative date for side-tag merge is 2015-01-28
19:10:37 <sgallagh> (In case you missed it)
19:10:43 <jreznik> ok
19:10:51 <mitr> Do we need a more targeted announcement to the side-tag owners?
19:11:21 <sgallagh> I think we need to make a devel-announce posting regarding the schedule in general (particularly the stricter contingency enforcement)
19:11:23 <jreznik> mitr: I can add it into the schedules reminder I'm going to send
19:11:40 <jreznik> sgallagh: that's of course going to be part of ^^^
19:11:51 <sgallagh> OK, I'll leave it to you, then
19:12:01 <t8m> 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 <jreznik> but tomorrow
19:12:05 <sgallagh> #action jreznik to send schedule reminder announcement
19:12:11 <t8m> but that's for F23
19:12:35 <sgallagh> t8m: Usually it would be, but we were really close to the holidays with F21
19:12:42 <sgallagh> And everyone was burned out
19:12:49 <jreznik> t8m: just f21 broke everything we do but for f22/f23 we will be in better situation
19:12:59 <jreznik> sgallagh was faster
19:13:00 <mitr> t8m: We do accept change proposals much earlier (like we did discuss dnf for F22).
19:13:22 <mitr> It’s just that they mostly arrive before the deadlines ☺
19:13:27 <jreznik> and /me delayed it a bit too :(
19:13:50 <jreznik> mitr: that's another point, day before deadline is the right time to start writing change page :)
19:14:08 <sgallagh> OK, so we didn't formally agree on the current schedule, but it sounds like we're good with it?
19:14:20 <jwb> yes
19:14:22 <t8m> sgallagh, +1
19:14:27 <kalev> yep
19:14:29 * nirik nods
19:14:39 <thozza> yes
19:14:57 <mattdm> yes
19:15:02 <mitr> Yes
19:15:08 <sgallagh> #agreed FESCo approves the current proposed schedule with a planned final delivery on 2015-05-19 (+8, 0, -0)
19:15:19 <sgallagh> (including my implied +1)
19:15:56 <sgallagh> Given the time, do we want to punt on the EOL and replacement tickets this week and get to the Changes?
19:16:08 <jwb> yes
19:16:23 <kalev> let's
19:16:40 <jreznik> well, for EOL - if you can comment in the ticket, would be great
19:16:46 <sgallagh> #topic #1198 Possible changes to Fedora EOL bug procedure
19:16:46 <sgallagh> #info FESCo punted on this until next meeting
19:16:47 <sgallagh> #topic #1326 change to fesco replacement process?
19:16:47 <sgallagh> #info FESCo punted on this until next meeting
19:16:48 <jreznik> especially that warning part
19:16:57 <sgallagh> #topic #1378 F22 System Wide Change: Elasticsearch - https://fedoraproject.org/wiki/Changes/Elasticsearch
19:16:57 <sgallagh> .fesco 1378
19:16:58 <zodbot> sgallagh: #1378 (F22 System Wide Change: Elasticsearch - https://fedoraproject.org/wiki/Changes/Elasticsearch) – FESCo - https://fedorahosted.org/fesco/ticket/1378
19:17:08 <t8m> sgallagh, shouldn't there be FESCo elections just now?
19:17:18 <jreznik> so actually I'd prefer EOL first than changes
19:17:25 <sgallagh> #undo
19:17:25 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x7959090>
19:17:26 <sgallagh> #undo
19:17:27 <zodbot> Removing item from minutes: INFO by sgallagh at 19:16:47 : FESCo punted on this until next meeting
19:17:27 <jreznik> t8m: it was my topic for open floor
19:17:28 <sgallagh> #undo
19:17:28 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0xaf72090>
19:17:31 <sgallagh> #undo
19:17:31 <zodbot> Removing item from minutes: INFO by sgallagh at 19:16:46 : FESCo punted on this until next meeting
19:17:41 <sgallagh> #undo
19:17:41 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0xe0dbcd0>
19:17:46 <sgallagh> #topic #1198 Possible changes to Fedora EOL bug procedure
19:17:52 <sgallagh> /me rewinds
19:18:01 <mattdm> okay so this is in progress
19:18:13 <t8m> jreznik, I am ok with your proposal to the EOL bug procedure
19:18:15 <jreznik> to make it fast - due to my faulty brain, I messed warning part that should run before break
19:18:37 <mattdm> jreznik there was some mail from you when I was on vacation about the CLOSED:EOL name problem <- my fault
19:18:40 <sgallagh> .fesco 1198
19:18:42 <zodbot> sgallagh: #1198 (Possible changes to Fedora EOL bug procedure) – FESCo - https://fedorahosted.org/fesco/ticket/1198
19:18:46 <jreznik> and we're already EOL - do we want to run short warning? or proceed with clossure?
19:18:51 <jreznik> mattdm: it's fixed now
19:18:58 <jreznik> so CLOSED:EOL is now fixed, it's EOL
19:18:59 <mattdm> jreznik: awesome thanks for taking care of that
19:19:10 <mattdm> do we have the changes in place which allow people to reopen?
19:19:30 <jreznik> other stuff like only selected user can use EOL resolution means coding on BZ side, they are looking on it
19:19:35 <kalev> if we have the changes in place that allow reopening EOL tickets, I'd go directly to closing
19:19:48 <nirik> jreznik: I never saw a reply to your thing about a group perm for EOL. Did that get sorted?
19:19:53 <t8m> I don't think we have.
19:20:01 <jreznik> mattdm: that's what I'm not sure, would be nice to check
19:20:09 <mattdm> 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 <jreznik> nirik: the answer from BZ team was that it probably needs some coding on BZ side
19:20:27 <nirik> jreznik: ok. ;(
19:20:29 <mattdm> 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 <nirik> can we not test with partner-bugzilla?
19:21:05 <jreznik> nirik: we can probably test on some of victim bugs... there are many to try it :)
19:21:22 <mattdm> remainig respondants still seemed amenable to doing it, though. :)
19:21:37 <mattdm> proposal: send EOL warning now, wait until those scripts are in place to actually close
19:21:48 <jwb> sure
19:21:58 <jreznik> 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 <nirik> well, partner-bugzilla has the advantage of not sending any emails. ;)
19:22:11 <jreznik> mattdm: yeah, that was my proposal
19:22:21 <nirik> jreznik: we don't remove the version... they are all still there back to fc1.
19:22:29 <jreznik> nirik: I have flag in my script not to send mails (it's in XML RPM)
19:22:31 <jreznik> RPC
19:23:12 <mattdm> jreznik: you mean without additional scripting? I think it just leaves version same.
19:23:15 <jreznik> mattdm: for sending EOL warning - month period? to sort it out or shorter?
19:23:35 <mattdm> jreznik: You talked to the bugzilla people more recently. what do you think?
19:23:47 <jreznik> mattdm: should be easy to try it, I'll check tomorrow or anyone faster pls comment in ticket
19:24:00 <mattdm> (also, I kind of think not sending email defeats half the purpose.)
19:24:10 <nirik> mattdm: just for testing... not the real thing
19:24:17 <jreznik> mattdm: not sending mails for testing only
19:24:18 <mattdm> nirik: ah okay good :)
19:24:34 <jreznik> or I can test on my own bugs
19:24:45 <jwb> need to drop for one second.  back shortly
19:25:06 <jreznik> 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 <jreznik> at least for EOL clossure
19:25:32 <jreznik> so let's go with month notice warning now, I can start tomorrow
19:25:38 <mattdm> jreznik: +1
19:25:40 <jreznik> and do some testing what's possible in current bz
19:25:46 * nirik thinks a month is a bit long.
19:25:56 <t8m> jreznik, +1
19:25:57 <sgallagh> Two weeks?
19:25:59 <nirik> but I guess it doesn't matter too much...
19:26:06 <jreznik> f14/f15 was closed after several years :)
19:26:31 <jreznik> nirik: if some changes will be needed in bz, it's not too long
19:26:39 <nirik> true... ok, a month it is then
19:26:53 <kalev> 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 <sgallagh> /me just applies a filter
19:27:37 <jreznik> kalev: percentage of people who really reacts is pretty low but maybe better than nothing
19:27:39 <nirik> anyhow, move on now?
19:27:39 <sgallagh> Anyway, ok. Send warning today, close in a month
19:27:47 <jreznik> sgallagh: yep
19:27:50 <mattdm> 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 <jreznik> and with mattdm we will follow up with bugzilla guys
19:28:14 <sgallagh> #info F19 EOL warning will be sent today. We will auto-close all remaining bugs in one month.
19:28:23 <sgallagh> #topic #1378 F22 System Wide Change: Elasticsearch - https://fedoraproject.org/wiki/Changes/Elasticsearch
19:28:23 <sgallagh> .fesco 1378
19:28:24 <zodbot> sgallagh: #1378 (F22 System Wide Change: Elasticsearch - https://fedoraproject.org/wiki/Changes/Elasticsearch) – FESCo - https://fedorahosted.org/fesco/ticket/1378
19:28:31 <nirik> +1
19:28:46 <t8m> +1
19:29:02 <jwb> +1
19:29:03 <kalev> +1
19:29:12 <sgallagh> I'm somewhat nervous about this, honestly.
19:29:19 <mitr> +1, though a little worried whether everyone will be able to keep all of the packages in sync over time.
19:29:21 <thozza> sgallagh: why?
19:29:49 <sgallagh> The Change proposal is really vague.
19:30:05 <mitr> 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 <sgallagh> 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 <mattdm> Right, this is a prime example of the tradeoff we get with strict no-bundling policies.
19:31:01 <jreznik> 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 <sgallagh> 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 <mitr> Sadly? the practice of library$version packages has become very widespread so there is ample precedent that it is _possible_.
19:31:28 <jreznik> sgallagh: SCLs would be great for such change...
19:31:39 <sgallagh> Sure... that's not going to happen for F22, last I checked.
19:31:44 <thozza> sgallagh: that sounds reasonable
19:31:51 <jwb> i +1'd this with the full expectation that we'd have to +1 some bundling exceptions for it
19:31:52 <mitr> 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 <sgallagh> jwb: If that's an expectation, we should state it outright.
19:32:20 <kalev> we can also allow bundling for some stuff if it's too painful to keep the versions in sync otherwise
19:32:22 <jwb> ok.  i just did :)
19:32:37 <jwb> or SCLs might work
19:32:56 <sgallagh> 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 <thozza> kalev: I would not state it explicitly now
19:33:19 <nirik> sgallagh: then if there is enough pressure, it can update and ES can make a compat package
19:33:28 <mattdm> jwb: so this would include a request to FPC to allow bundling exceptions for this package?
19:33:50 <jwb> 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 <mattdm> 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 <sgallagh> mattdm: I know, this is an old argument.
19:34:23 <thozza> mattdm: why do we want to approve it before it even happened?
19:34:28 <kalev> then someone would have to do the usual dance of backporting the patch
19:34:34 <jreznik> 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 <t8m> jreznik, +1
19:34:59 <sgallagh> I'm okay with approving it with a blanket exception to the bundling policy
19:35:03 <mattdm> 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 <sgallagh> Provided that FPC accepts that
19:35:20 <sgallagh> (or accepts our authority to decide that, I should say)
19:35:23 <t8m> sgallagh, I don't agree with such blanket exception
19:35:27 <mitr> sgallagh: I’d much rather not have that blanket exception.  Compat packages are better.
19:35:35 <t8m> mitr, +1
19:35:41 <thozza> mitr: +1
19:35:50 <mattdm> So should we ask for compat packages as the contingency plan?
19:35:55 <mitr> (And they are a bigger hurdle to motivate people to keep with one version :) )
19:36:16 <mitr> mattdm: The contingency plan for F22 is very plausibly “not ship it”, that’s the easy part
19:36:29 <jwb> i find compat packages to be amusing
19:36:56 <jwb> 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 <sgallagh> There's no contingency plan listed at all right now
19:37:23 <mattdm> sgallagh: right. and as per above, we should not approve this without one.
19:37:30 <sgallagh> yes
19:37:43 <jreznik> change owner is going back in two weeks
19:37:57 <mitr> jwb: They are clearly better than >1 bundled copy in that respect.  No, they don’t ensure vulnerabilities get fixed.
19:37:59 <sgallagh> going back?
19:38:00 <jwb> oh, i missed that they didn't add a contingency plan.  my mistake
19:38:29 <jreznik> and my mistake too not checking it properly
19:38:39 <jreznik> sgallagh: he's out for a few weeks
19:38:40 <jwb> i'm changing my vote to a -1
19:38:40 <mattdm> There is some text in the contingency plan section, but it's basically _risks_, not fallback positions
19:39:01 <jreznik> well, fallback is easy - no elasticsearch
19:39:09 <sgallagh> I'm going to stick with -1. As written, I don't want to accept this.
19:39:11 <mitr> 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 <t8m> same as mitr
19:39:27 <jreznik> mitr: yeah, I ask to fix it and resend
19:39:30 <sgallagh> jreznik: Well, it may in fact have an effect on what versions of it deps we would ship.
19:39:49 <mattdm> +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 <sgallagh> 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 <mitr> So, send back for 1) contingency plan revision?  or 2) completely change of approach?
19:40:35 <mitr> (I am +1 -1 at the moment)
19:40:55 <kalev> mitr: I'm +1 -1 too
19:40:55 <mattdm> elasticsearch is cool and it'd be _nice_ to have it, but, yeah.
19:40:56 <nirik> sure, we should require a contingency plan...
19:41:03 <thozza> mitr: +1
19:41:12 <mattdm> I don't see a COPR -- that would make a good proving ground.
19:41:24 <t8m> mitr, I am +1 -1 as well
19:41:29 <thozza> mattdm: yes, that would be great
19:41:30 <sgallagh> 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 <sgallagh> It gives them a specific mission to accomplish, rather than generic solutions
19:42:05 <jwb> them being who?
19:42:09 <jwb> Env/Stacks?
19:42:11 <sgallagh> jwb: Env/Stacks
19:42:22 <nirik> I'm not sure what this wider solution would be...
19:42:34 <jwb> seems like a good challenge for them, but i don't think it's fair to the Elastic packagers
19:42:37 <t8m> I don't think we should take a Change for a hostage
19:42:41 <jwb> and i don't see why it can't be done in parallel
19:42:49 <t8m> jwb, +1
19:43:07 <sgallagh> 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 <mattdm> yeah I agree with parallel, as long as there are people interested in actually working on parallel approaches.
19:43:33 <jwb> sgallagh, if packagers can ignore a WG, they can ignore the FPC, FESCo, and pretty much anyway
19:43:36 <nirik> right, all we know now is someone is willing to work on packaging it.
19:43:37 <jwb> er, anyone
19:43:48 <jwb> so it's up to us to give them incentive to work with Env/Stacks for an F23 solution
19:43:57 <jwb> while not arbitrarily holding them up
19:44:14 <jwb> and if that incentive is "if you ignore Env/Stacks, we punt your package", well...
19:44:28 <thozza> they can always use COPR in the meanwhile
19:44:35 <jwb> they could, this is true
19:44:48 <nirik> I don't think threatening them is good...
19:44:56 <mattdm> 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 <mitr> 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 <sgallagh> I don't want to threaten them.
19:45:04 <mitr> mattdm: yes
19:45:11 <jwb> nirik, no, but assumign they're going to ignore Env/Stacks isn't good either.
19:45:15 <sgallagh> Though I admit, it would probably come across that way
19:45:17 <mattdm> 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 <thozza> mitr: that's why it is "in the meanwhile"
19:45:57 <mitr> 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 <nirik> 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 <t8m> nirik, +1
19:46:37 <kalev> nirik: yes, I don't think we should hold up packaging for this either
19:47:30 <sgallagh> My major concern is the potential for "locking" package versions.
19:47:45 <mitr> mattdm: <tired>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</tired>
19:47:52 <sgallagh> I don't believe (from this Change page) that the proposers have a sufficient plan in place for avoiding that.
19:48:11 <jwb> sgallagh, so vote -1, tell them to address it in an update and resubmit
19:48:23 <sgallagh> jwb: I thought I said that ten minutes ago...
19:48:26 <mattdm> yep. let's do that and move on to the next thing :)
19:48:30 <jwb> then why are we still talking about this?
19:48:35 <mattdm> meeting fatigue is setting in
19:48:43 <jwb> proposal: STOP TALKING ABOUT THIS
19:48:48 <t8m> mattdm, it looks like that
19:48:56 <jwb> i have to leave in like 3 minutes for good this time
19:49:04 <mitr> So, to simplify:
19:49:16 <mitr> Proposal: The approach is OK, please resubmit with a real contingency plan.
19:49:19 <mitr> yes?no?
19:49:22 <t8m> mitr, +1
19:49:22 <sgallagh> 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 <thozza> mitr: +1
19:49:52 <nirik> mitr: +1
19:50:01 <kalev> mitr: +1
19:50:04 <jwb> +1 i think
19:50:34 <sgallagh> mattdm: ?
19:50:40 <mattdm> mitr: +1. If contingency plan involves new compat packages or similar, needs to specify who will actually do that
19:50:50 <mitr> (For the record I would stop short of saying “this approach is recommended”, sgallagh does have valid concerns.)
19:51:03 <sgallagh> #agreed Change is approved. The approach is OK, please resubmit with a real contingency plan. (+7, 0, -1)
19:51:28 <sgallagh> #topic #1379 F22 System Wide Change: Change xorg input stack to use libinput - https://fedoraproject.org/wiki/Changes/LibinputForXorg
19:51:28 <sgallagh> .fesco 1379
19:51:29 <zodbot> 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 <mitr> 2 concerns:
19:51:53 <mitr> 1) KKofler mentioned that KDE has a synaptics control panel; do we know who will take care of porting it?
19:52:29 <mitr> 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 <mitr> (/me apologizes for not raising 2) before, still recovering from a long PTO and email outage)
19:52:53 <nirik> on 2... probibly need to add that those would have to be reverted too
19:53:59 <sgallagh> 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 <nirik> yeah, they are both release blocking. ;)
19:54:24 <mitr> works for me
19:54:34 <sgallagh> 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 <sgallagh> *date
19:54:51 <t8m> sgallagh, +1
19:54:57 <kalev> works for me too, good idea to specify this
19:54:58 <kalev> +1
19:55:09 <mattdm> +1 to that. It looks like the contingency plan is an easy switch back
19:56:12 <nirik> +1
19:56:15 <sgallagh> 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 <mitr> sgallagh: +1
19:56:28 <mattdm> sgallagh: +1
19:56:33 <sgallagh> +1
19:56:36 <kalev> sgallagh: +1
19:56:41 <thozza> sgallagh: +1
19:57:10 <t8m> sgallagh, +1
19:57:46 <sgallagh> #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 <sgallagh> (I assumed that nirik's +1 carried over. Correct me if I'm mistaken)
19:58:00 <nirik> yeah, +1
19:58:15 <sgallagh> Last one:
19:58:16 <sgallagh> #topic #1380 F22 System Wide Change: wxPython 3 - https://fedoraproject.org/wiki/Changes/wxPython3
19:58:17 <sgallagh> .fesco 1380
19:58:18 <zodbot> sgallagh: #1380 (F22 System Wide Change: wxPython 3 - https://fedoraproject.org/wiki/Changes/wxPython3) – FESCo - https://fedorahosted.org/fesco/ticket/1380
19:58:22 <mitr> +1
19:58:27 <nirik> +1
19:58:47 <kalev> +1
19:58:50 <sgallagh> +1
19:58:55 <thozza> +1
19:58:57 <t8m> +1
19:59:06 <sgallagh> Though I question why they have a separate contingency deadline...
19:59:21 <sgallagh> Beta freeze is probably too late.
19:59:48 <mattdm> oh geez i used to maintain this package and I'm glad someone else does now :)
19:59:48 <t8m> sgallagh, +1
20:00:28 <sgallagh> Addendum to the acceptance: must meet the same contingency date as everything else?
20:00:43 <mattdm> sgallagh: +1 to that addendum
20:00:51 <thozza> sgallagh: +1
20:00:56 <kalev> +1
20:00:57 <mattdm> I'm -1 overall otherwise.
20:01:12 <nirik> +1 to that...
20:01:52 <mitr> sgallagh: What do you mean by "separate" deadline?  Beta freeze is the standard one.
20:02:21 <sgallagh> mitr: "2015-02-24: Change Checkpoint: Completion deadline (testable)"
20:02:51 <sgallagh> I mean that any dependent rebuilds need to be done by Alpha.
20:02:58 <sgallagh> Bugs can be fixed until Beta before reverting.
20:03:07 <t8m> sgallagh, +1 to the addendum
20:03:20 <mitr> sgallagh: but contengency deadline is “When is the last time the contingency mechanism can be put in place?”
20:03:30 <mitr> That change checkpoint still applies
20:03:30 <sgallagh> Good point.
20:03:39 <sgallagh> Sorry, getting tired.
20:03:47 <sgallagh> My addendum is therefore completely redundant.
20:03:47 <mitr> (Though, to be fair, I was equally confused and thinking the same thing as you about what the deadline means.)
20:04:30 <mattdm> meeting fatigue strikes again!
20:04:45 <sgallagh> #agreed Change is approved. (+7, 0, -0)
20:04:53 <sgallagh> #topic Next week's chair
20:05:01 <sgallagh> /me tosses the grenade
20:05:10 <sgallagh> Who's going to fall on it this week?
20:05:23 <jreznik_pp> Btw elections should start soon
20:05:38 <mattdm> jreznik_pp: -> next open floor topic?
20:05:47 * mattdm looks around shifty-eyed
20:05:59 <mattdm> okay fine I'll do it :)
20:06:14 <sgallagh> #info mattdm to chair next week's meeting
20:06:18 <jreznik_pp> Oops, sorry, I saw grenade on this meeting, not chair, heh
20:06:19 <sgallagh> #topic Elections
20:06:33 <jreznik_pp> Draft is on elections page
20:06:39 <sgallagh> link?
20:06:47 <jreznik_pp> I'm on phone
20:07:08 <jreznik_pp> http://fedoraproject.org/wiki/Elections
20:07:12 <sgallagh> #link https://fedoraproject.org/wiki/Elections
20:07:48 <jreznik_pp> No FAmSCo this time but env and stacks
20:08:07 <jreznik_pp> Mattdm, pls take a look
20:08:16 <nirik> seems fine to me
20:08:22 * mattdm looking
20:08:35 <jreznik_pp> We will need announcement ;-)
20:08:40 <sgallagh> Sounds good to me
20:08:46 <mattdm> yeah looks good to me too
20:08:56 <mattdm> jreznik_pp: you want annoucnement from me or you wanna do it?
20:09:16 <jreznik_pp> I don't mind doing it
20:09:39 <mattdm> jreznik_pp: help yourself :)
20:09:50 <mattdm> I can help with Fedora Magazine again.
20:10:02 <jreznik_pp> Ok
20:10:14 <jreznik_pp> We will sync over next few days
20:10:21 <mattdm> FTR I don't plan to run again. It's been fun. :)
20:10:43 <jreznik_pp> All from me today
20:10:55 <jreznik_pp> Time to get off the bus
20:11:17 <sgallagh> Any opposition to the proposed election schedule?
20:11:20 <nirik> mattdm: it's like you're busy with other stuff or something. ;)
20:11:40 <t8m> sgallagh, no
20:11:57 <sgallagh> #info Elections will open for nominations on January 13th. Voting will open on January 27th.
20:12:03 <sgallagh> #topic Open Floor
20:12:57 <sgallagh> Anything, or are we all well and truly out-meetinged?
20:13:03 * mattdm falls over
20:13:14 <t8m> completely
20:13:26 <thozza> end it :)
20:13:27 <sgallagh> Thanks for sticking it out this far, folks
20:13:30 <sgallagh> #endmeeting