16:00:18 <stickster> #startmeeting Fedora Workstation WG
16:00:18 <zodbot> Meeting started Wed Dec 17 16:00:18 2014 UTC.  The chair is stickster. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:18 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:21 <stickster> #meetingname workstation
16:00:21 <zodbot> The meeting name has been set to 'workstation'
16:00:27 <stickster> #topic Roll call!
16:00:34 * stickster o/
16:00:42 <jwb> \o
16:00:59 <kalev> \o/
16:01:20 <rdieter> here
16:01:23 <cschalle_> \O/
16:02:09 * stickster looks for mclasen ryanlerch otaylor juhp cwickert
16:02:26 * mclasen is here
16:03:04 * stickster will sneakily inject one quick agenda item at top before change stuff
16:03:14 <stickster> #chair mclasen cschalle_ rdieter kalev jwb
16:03:14 <zodbot> Current chairs: cschalle_ jwb kalev mclasen rdieter stickster
16:03:34 <stickster> I guess we have a bare quorum? (5 of 9 members)
16:03:59 * stickster will move ahead expeditiously, knowing that people are probably ready for some holiday time off. :-)
16:04:07 * ryanlerch is here
16:04:15 <stickster> #chair ryanlerch
16:04:15 <zodbot> Current chairs: cschalle_ jwb kalev mclasen rdieter ryanlerch stickster
16:04:21 <stickster> yay, that's 6/9 :-)
16:04:28 <stickster> #topic Surprise topic: F21
16:04:45 <stickster> I forgot to note that, since last meeting, F21 is released!  \o/ \o/ \o/ \o/ \o/
16:04:54 <jwb> so old.
16:04:55 <stickster> I know it seems like old news, being a WHOLE WEEK AGO
16:05:14 <stickster> But reviews have been *really* good relative to most other releases
16:05:47 <stickster> #info F21 Workstation is out, it's awesome, and congrats to everyone. That is all.
16:06:09 <stickster> So moving on...
16:06:12 <stickster> #topic Change proposals
16:06:19 <stickster> #url http://fedoraproject.org/wiki/Workstation/Tasklist
16:07:15 <stickster> So there's a rather voluminous and interesting list of next steps in the wiki. I reviewed with mclasen last week, and we marked a bunch of them with check-marks to show which ones we think merit Change proposals for the formal FESCo process
16:08:08 <mclasen> I'll file at least the gnome-shell and nautilus ones, when the first chunks of that work land upstream
16:08:27 <stickster> #info Current Change checkpoint is proposed for 2015-Jan-20, so about 2.5 or 3 weeks after holiday
16:08:57 * mclasen is off until jan 6
16:09:26 <stickster> Thanks mclasen... No intent to step on your toes, since you've been doing this for previous releases... but do you need help with filing others?
16:09:45 <stickster> mclasen: Yeah, I'm gone after this Friday 2014-Dec-19, until Monday 2015-Jan-05
16:10:09 <mclasen> maybe, but I don't want to file change requests for things where I'm not confident that they'll happen for f22
16:10:32 <mclasen> therefore I'd rather wait until january
16:11:00 <stickster> mclasen: We have a meeting scheduled for 2015-Jan-07 (based on no objections from the list to date AFAIK) so we don't get too far toward the checkpoint without meeting up... should we check then?
16:11:11 <mclasen> sounds right
16:11:19 <stickster> Or maybe just make that the point where we start rounding up what needs to be filed :-)
16:11:35 <mclasen> maybe related to change requests - does the schedule currently look like it'll fit gnome 3.16 ?
16:11:45 <stickster> #action mclasen file gnome-shell + nautilus related changes
16:12:16 <stickster> #action stickster Put remaining Change items on agenda for 2015-Jan-07 to check outlook for landing
16:12:34 <kalev> yes, we have plenty of time to get gnome 3.16 in
16:12:52 <kalev> F22 final freeze is currently schedule for not earlier than 2015-05-05
16:13:06 <kalev> and 3.16.1 is 2015-04-13
16:13:35 <mclasen> looks like the usual tight fit, ok
16:14:15 <stickster> Yeah, currently it looks like the way the schedule meets up, we'd have stable in for beta freeze (barely)
16:14:47 <kalev> http://fedoraproject.org/wiki/Releases/22/Schedule and https://wiki.gnome.org/ThreePointFifteen if anyone else wants to compare
16:14:53 * stickster holds thoughts on Fedora slippage :-)
16:15:15 <rdieter> stickster jinxed it now
16:15:24 <stickster> #info Current GNOME 3.16 schedule looks like a tight but workable fit for current Fedora 22 proposed schedule
16:15:27 <jreznik> let me know if you'd need anything regarding changes
16:15:30 <stickster> rdieter: D'OH!
16:16:38 <stickster> One thing I've been thinking about wrt. changes + tasklist is whether we need to also be driving any feature specification from our bigger-picture PRD for Workstation
16:18:31 <stickster> We have several really good stories emerging in the tasklist for things like Wayland, notifications, more native app/environment smoothing (Qt theming, et al.)...
16:18:32 <mclasen> that would be nice, certainly
16:19:45 <stickster> But it seems to me we might also have specific things to improve/create with a top-down focus as well
16:21:37 <stickster> That seems like something WG folks can effectively discuss/collaborate on to improve the Workstation over a release or two
16:22:21 <stickster> ryanlerch mentioned something on list yesterday about upgrade notifications, for example
16:22:46 <jwb> was just going to ask if you had an example since i was a bit lost as to what you were driving towards
16:23:42 <stickster> jwb: *nod. I need to go back to PRD and re-read for some other ideas as well, but that's a very good example IMHO because the only way you can currently know about our release stuff is to be "dialed in" via some social media or community group, and we shouldn't be expecting that of every user
16:23:51 <mclasen> big picture items from my perspective are a) finish wayland port to the point where its feature-complete b) get started with app bundles/sandboxing/3rd party applications and c) unified platform (qt integration, etc)
16:23:53 <stickster> Wow. That was a very long sentence.
16:24:20 <mclasen> most of the tasks on the task list are more or less in support of one of those
16:25:22 <stickster> mclasen: Agreed, those seem quite critical path... I think there's some latitude for things that are specific to Fedora Workstation, but also need some direct discussion/ideation, design, and coding
16:25:54 <jwb> so one thing to keep in mind about big picture items... they often impact people outside the WG itself.  e.g. app bundles need to be distributed, and Fedora isn't setup to do that at all yet
16:26:11 <mclasen> I'll note that my big-picture item list misses anything developer-specific, really
16:26:22 <jwb> wayland is a bit more manageable/self-contained
16:26:30 <jwb> as is the QT integration
16:26:33 <stickster> jwb: That's a good point
16:26:42 <mclasen> that is very true
16:26:50 <jwb> so if we're going to tackle app bundles, it's probably an f23/f24 item and really needs to be driven throughout starting now
16:27:01 <stickster> #info jwb points out that some upstream stuff will require Fedora-specific work outside the WG, e.g. app bundles
16:27:12 <mclasen> alex is giving a talk at devconf about his app bundle work
16:27:35 <jwb> how would creation look?  how would delivery look?  what resources do we need?  what changes do we need from rel-eng?  do we update components within the app bundles and ship "updates" for them?
16:27:44 <stickster> mclasen: Do you know if there's any good summary documentation currently about that topic, how app bundles are envisioned to work?
16:28:08 <jwb> and of course kind of the kicker here: will FESCo/Council sign off on this within Fedora?
16:28:29 <jwb> i'd love to see alex's talk.  i'll make it a priority
16:28:32 <stickster> Is this https://people.gnome.org/~alexl/glick2/ ?  Or has that moved on a bunch?
16:28:34 <mclasen> there's several things, I can go and dig a bit
16:28:39 <ryanlerch> also, and what is the net benefit to our end users?
16:28:47 <mclasen> glick and glick2 were earlier attempts
16:28:53 <jwb> ryanlerch, yes!
16:28:54 <mclasen> the current work is based on ostree
16:29:20 <jwb> i think app bundles will be beneficial for a number of reasons, but i don't want a repeat of SCLs
16:29:33 <stickster> mclasen: Right, I would expect ostree to be relevant here... So digging up a current summary we can use to start wider discussion would be a great place to start
16:29:40 <stickster> jwb: +100
16:29:45 <jwb> and i kind of think the benefits aren't for _fedora_, but more for end users/developers
16:29:51 <jwb> and fedora benefits indirectly
16:29:56 <jwb> which is sometimes a hard sell
16:30:15 <mclasen> ryanlerch: the end goal would be that 3rd parties can provide app bundles that can run across distros
16:30:16 <stickster> ironic, since you'd think "make something great and people will think you're great" would be an easy sell
16:30:38 <jwb> stickster, depends on who's doing the making
16:30:43 <mclasen> ryanlerch: you can probably see already where this might cause some headscratching in a packager world...
16:31:12 <ryanlerch> mclasen, yeah :)
16:31:33 <stickster> jwb: Good point. Let's adopt a lovable mascot
16:32:44 <stickster> mclasen: ryanlerch: Sure -- but it's a problem we'll have to solve in a brighter world where people can get interested in the Fedora ecosystem including CentOS and even RHEL
16:32:48 <cschalle_> stickster, +1 for Mogwai to be our new mascot then :)
16:32:57 <jwb> oh my
16:33:01 <stickster> cschalle_: You know what happens when you feed them after midnight
16:33:08 <jwb> or get water on them
16:33:25 <mclasen> the starting point would be to get (some) applications inside the distro converted to use the bundle format, maybe still wrapped in rpm
16:33:38 <jwb> mclasen, like firefox?
16:34:05 <stickster> jwb: Ooo, that's an interesting one.
16:34:06 <mclasen> cschalle loves the idea that mozilla might ship an app bundle to get us out of being the middle man
16:34:24 <cschalle_> I do :)
16:34:38 <stickster> So I seem to have taken us far afield of the topic :-)  I do that sometimes.
16:34:41 <jwb> so... just to get this out of the way.  these bundles should be consumable on a wide variety of platforms, right?
16:35:04 <jwb> like... firefox 456 bundle that runs on fedora, rhel, centos, etc
16:35:20 <cschalle_> ideally yes
16:35:25 <mclasen> that is one of the points, yes. that is the incentive for 3rd parties to use them
16:35:44 <jwb> so offering infrastructure for 3rd parties to use to _create_ those bundles might be a good approach
16:36:07 <stickster> If we can get a broad consensus on app bundles it also might (finally) make it worthwhile for ISVs to build something for Fedora.
16:37:04 <jwb> we'd likely need the creation infrastructure anyway if we're targeting Workstation as something developers would use to create their app.  now they can create the app, create the bundle, and it runs everywhere*
16:37:12 <jwb> (*no guarantee it will run everywhere)
16:37:25 <stickster> :-)
16:37:34 <stickster> Wait, we're not talking about NIH'ing OBS?
16:37:43 <mclasen> I need to catch up with alex anyway, I'll see if he has any thoughts on tooling
16:37:59 <jwb> being fair, i don't think we care if bundles run on fedora and gentoo.
16:38:35 <mclasen> most 3rd parties will care if they run on ubuntu...
16:38:49 <jwb> yes
16:38:53 <mclasen> which is a bit of a sore point, since they go their own way with click...
16:39:07 <ryanlerch> so for the end user, this will just make it easier to run 3rd party stuff? i.e. things like spoitfy or steam?
16:39:09 <jwb> well, we've got similar issues with docker/rocket too
16:39:22 <jwb> having a tool to convert to click isn't a terrible idea
16:39:31 <jwb> but that means we have to have something to convert _from_ already ;)
16:39:41 <jwb> ryanlerch, yes
16:39:43 * stickster thinks before we get too far down this road -- maybe we should come back to main point, which is big-picture approach... we have at least two current ideas in this space: (1) aforementioned app bundles, *big* work but *big* reward; (2) upgrade notifications, smaller work and smaller reward; (1) probably a multi-release plan, (2) might be do-able in F22
16:40:02 <mclasen> if thats feasible (conversion), sure. I'll ask alex
16:40:03 <jwb> ryanlerch, well, maybe.  colin thinks containerized desktop apps are very hard to do because of all the ipc
16:40:16 <jwb> but yes, i think that's probably a goal here
16:40:32 <jwb> stickster, yes
16:41:02 <mclasen> upgrade notification should not be a big deal, I'm pretty sure we can get that done for f22
16:41:05 * stickster hates to be a tree-and-not-forest-oriented person because this discussion ROCKS. But we do have a couple other things on the agenda we should at least touch on.
16:41:21 <jwb> sure, we can move on
16:41:24 <mclasen> of course, the notification won't do much good unless the upgrade works flawlessly in almost all situations
16:42:19 <stickster> mclasen: We don't have a good way to gather "how did your upgrade go". So far anecdata seems to say quite good, but you know how that goes.
16:42:56 <kalev> upgrade notification itself should be pretty simple, but it gets trickier if we want to have a GUI for doing the actual upgrade
16:43:29 <stickster> kalev: Right. And we'd probably want to solve this in a way that worked across the offerings
16:43:32 <mclasen> what does that mean ? fedup is using the same systemd mechanism for rebooting into a special mode to do the work, no ?
16:44:00 * stickster notes we're rat-holing away from the agenda, even if it is a luxurious and attractive hole
16:44:01 <ryanlerch> kalev, won't the upgrade GUI pretty much just be a button to start it?
16:44:42 <kalev> mclasen: it actually uses a different systemd target than the packagekit offline updater
16:44:58 <mclasen> sure, but its still the same mechanism, basically
16:45:04 <mclasen> anyway, lets take the details out of this meeting
16:45:16 <mclasen> I'll inquire if we have mockups for the ui portion of this
16:45:25 <stickster> #info Current big-picture, more Fedora-WS-oriented improvements: (1) app bundles (high effort, multi-release); (2) upgrade notifications (lower effort, maybe F22 doable)
16:45:42 <ryanlerch> mclasen, i have a few ideas in my head that was intending to do mockups for
16:45:48 * mclasen adds the upgrade notification to the tasklist, for completeness
16:46:00 <stickster> #action mclasen dig up summary/details on current app bundles effort so we can understand state upstream
16:46:34 <jwb> i look forward to the "privacy" concerns coming from finding out if there's an upgrade available.
16:46:34 <stickster> #action mclasen look for mockups for UI portion of upgrade notification (possibly execution?)
16:46:42 <stickster> jwb: AS DO I
16:46:58 <stickster> jwb: also the Privacy Spin
16:47:32 <stickster> Clearly this will be some great discussion for us in January, though. Seriously.
16:47:45 <mclasen> fyi, here is a different take on 'system upgrade': https://wiki.gnome.org/Design/OS/Migration
16:48:18 <stickster> #info For reference, a different implementation of upgrades: https://wiki.gnome.org/Design/OS/Migration
16:48:31 <jwb> that... doesn't look like upgrade
16:48:42 <mclasen> thats why I said 'different take'
16:49:08 <jwb> well, it would be if you could apply it to a single machine without having to do a fresh install :)
16:49:21 <stickster> *nod
16:49:24 * stickster is going to move on so we can at least hit one more thing before break
16:49:32 <stickster> #topic Resolving firewall question
16:49:32 <mclasen> in-place upgrades are always problematic - if you could conveniently save and restore all your data, you can avoid it...
16:49:35 <jwb> i mean, it looks really useful anyway, but it doesn't seem like a good fit for upgrading if you only have one machine or something
16:49:47 <jwb> yeah, lets move on
16:50:24 <stickster> So yes, we got a lot of noise (from arguably a small number of people) about firewall. But I did hear that some of the security folks were interested in what we do or don't plan to do in future for Workstation firewall
16:50:37 <jwb> yes
16:50:52 <jwb> mitr asked FESCo to hold off on deciding anything
16:50:57 <stickster> Do we have any consensus in the WG about our ideal desired state for the Fedora firewall "experience"?
16:51:37 <ryanlerch> stickster, is this the open ports thing?
16:51:52 <jwb> yes
16:51:56 <cschalle_> I think my 'rule of thumb' is that applications breaking 'silently' is an absolute no
16:52:00 <kalev> I guess everyone here would want newly installed apps to work out of the box, without the user having to go poke at the firewall manually
16:52:21 <kalev> how exactly that's implemented, that's probably secondary
16:52:27 <mclasen> in an ideal world, applications will be sandboxed, and giving them any form of network access will be an explicit user choice (perhaps as part of installing the app)
16:52:43 * ryanlerch taps out of this convo -- i don't have enough knowledge of networking security stuff to add anything
16:52:54 <stickster> ryanlerch: I have barely more, I've got your back :-)
16:53:14 <jwb> mclasen, even in today's world of RPMs, that can still apply.  you install the package, you grant network access.
16:53:40 <stickster> mclasen: jwb: Yeah, would it be possible to trigger that somehow for network-facing apps?
16:53:51 * stickster waves hands around wildly
16:53:54 <jwb> stickster, i think mclasen meant it was implicit upon install
16:54:25 <jwb> "oh, the user wanted to install this application.  it uses port 49857.  they wouldn't want it to be installed and not working, so poke a hole"
16:54:36 <jwb> (or in our existing case it will just work anyway)
16:54:40 <mclasen> I don't know that 'open the ports when I install this rpm' is much different from 'have this port open at all times', tbh
16:54:45 <jwb> right
16:54:53 <mclasen> and the big problem with all these approaches is dynamic ports
16:55:01 <cschalle_> actually I think the idea is more like Android, which asks you upon install 'I want to do this, is it ok?'
16:55:12 <stickster> mclasen++ -- it's more like a question for the app overall
16:55:26 <jwb> cschalle_, won't 95% of people just blindly click yes?
16:55:31 <ryanlerch> would messageing help here? when i install a package that opens a port it tells me that?
16:55:44 <cschalle_> jwb, sure, but 95% of people just disable their firewall today so no net loss ;)
16:55:47 <stickster> jwb: /me is the first to raise his hand and say he does this on Android ALL THE TIME
16:56:08 <jwb> cschalle_, i agree, but it's actually more work and hassle for the user than what we have right now
16:56:19 <jwb> maybe that's the compromise though
16:56:21 <mclasen> well, you don't really want to ask in the abstract 'do you want to allow app x to open port 12345'
16:56:40 <cschalle_> jwb, well my hope is that this information can be in GNOME Software at some point in the future, and thus not adding an extra step
16:56:43 <stickster> mclasen: More like "is it ok for app X to be on the network?" or something
16:56:44 <mclasen> but ask about a concrete thing: 'are you comfortable sharing your vacation photos on this network ?'
16:57:05 <randomuser> !
16:57:08 * rdieter thinks signed/trusted packages should 'just work' too, if that means automatically opening ports, so be it.
16:57:27 <stickster> rdieter: Good point -- there is a packager trust level here, too
16:57:38 <randomuser> mclasen, you can really only apply that kind of solution to apps you provide.  Anything a user gets from the wild isn't in scope
16:57:49 <stickster> rdieter: Although the automatic opening itself may be problematic when they're dynamic
16:58:07 <rdieter> stickster: true, means the app would have to manage that somehow too
16:58:10 * stickster wonders whether it would be possible to do this with existing SELinux policy somehow
16:58:19 <randomuser> ..which I guess is a good thing; applications from the wild shouldn't be trusted to behave
16:58:29 <stickster> Like all signed/trusted packages are in a specific context that's OK for high port access
16:58:41 <mclasen> I don't think this is about 'trusting' the package, at all - if you don't trust the package, don't install it
16:58:44 <mclasen> else its game over
16:58:50 * stickster quickly stops thinking implementation, before he hurts himself
16:59:21 <randomuser> mclasen, now you're trusting a user to understand the full function and behavior of a package, but not trusting them to flip the switch to use it
16:59:29 <stickster> OK, we have 2 minutes right now, and it sounds like we need more discussion of ideal firewall state on the list before we can get with FESCo for a reasonable summary + outlook for future
16:59:34 <stickster> sorry, 1 minute.
16:59:52 <stickster> ryanlerch: I didn't get to the triage question, but will carry it over
16:59:54 * randomuser </interruption>
16:59:55 <mclasen> randomuser: things are of course different for sandboxed apps - the entire point of a sandbox is to make it so that you don't have to trust it
17:00:04 <stickster> ^ this, right.
17:00:44 <randomuser> sure - I'm just thinking about the layer of protection for unintentional behaviors
17:00:56 <cschalle_> randomuser, I think the problem is that for a 3rd party package it is hard to enforce any way for them to behave that will let the user know the problem. Before 21 to much stuff just failed silently, and unless you realized it was the firewall blocking stuff you would just think the application or Fedora is broken
17:01:04 <stickster> We probably need to write up a wiki page or something about this to summarize (1) our assumptions, (2) our understanding of the problem, and (3) where we want to get to ideally.
17:01:09 <stickster> agh, we're overtime.
17:01:43 <stickster> Is the above a good way to describe something actionable we can work on after holiday?
17:01:50 <cschalle_> +1
17:01:53 <mcatanzaro> For today's FESCo meeting, where firewall is on the agenda, what is the plan? Ask for delay?
17:02:12 <jwb> probably
17:02:18 <mclasen> one more point to squeeze in, maybe - without sandboxing that allows us to clearly identify apps, it is really hard to make meaningful decisions about opening ports on-the-spot
17:02:34 <stickster> mcatanzaro: Yes. I think we want to show FESCo we're not disinterested in input, but we have specific opinion here and want to present the rationale and where we're heading.
17:02:41 <mclasen> I'll be there anyway, to answer questions
17:03:10 <mclasen> fesco meeting is an hour from now ?
17:03:14 <jwb> yes
17:03:14 <stickster> Also, it should be OK for WS/Server/Cloud to be different in this regard, because of different user expectations.
17:03:17 <stickster> mclasen: Correct.
17:03:38 <randomuser> depending on a whole sandboxing infrastructure to be used by Fedora and third parties to solve the 'open' firewall question seems premature
17:03:58 <stickster> #action stickster mclasen be around for FESCo meeting in ~1 hour if this topic comes up
17:04:09 <mclasen> I'd like to see some clarification coming out of this discussion about the extent to which we should expect fesco to second-guess every change we  make
17:04:16 <stickster> mclasen: +1
17:05:07 <stickster> #action stickster start discussion on desktop@ list toward a wiki page that covers our assumptions, problem statement, and our ideal Workstation approach for firewall
17:05:17 <stickster> OK, 5 min over, sorry guys. Anything else before we adjourn?
17:05:28 <stickster> #topic All other business
17:05:36 <mcatanzaro> mclasen: That's probably a question for the Council to decide: whether FESCo can overrule a WG with respect to the WG's product.
17:05:37 <stickster> #action stickster Carry over bug triage topic for next meeting
17:06:13 <stickster> mcatanzaro: I'm not sure that's in question. FESCo formed the WGs.
17:07:04 <stickster> Let's take that to #fedora-workstation if needed though, we're past time here...
17:07:08 <stickster> closing in 10
17:07:13 <jwb> mcatanzaro, it's not.  WGs report to FESCo.
17:07:15 <stickster> 5
17:07:25 <rdieter> mcatanzaro: I don't think it's a question either, FESCo certainly does have that ability, if it chooses (subject to board/council oversight of course)
17:07:25 <stickster> #endmeeting