16:00:18 #startmeeting Fedora Workstation WG 16:00:18 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:00:21 #meetingname workstation 16:00:21 The meeting name has been set to 'workstation' 16:00:27 #topic Roll call! 16:00:34 * stickster o/ 16:00:42 \o 16:00:59 \o/ 16:01:20 here 16:01:23 \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 #chair mclasen cschalle_ rdieter kalev jwb 16:03:14 Current chairs: cschalle_ jwb kalev mclasen rdieter stickster 16:03:34 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 #chair ryanlerch 16:04:15 Current chairs: cschalle_ jwb kalev mclasen rdieter ryanlerch stickster 16:04:21 yay, that's 6/9 :-) 16:04:28 #topic Surprise topic: F21 16:04:45 I forgot to note that, since last meeting, F21 is released! \o/ \o/ \o/ \o/ \o/ 16:04:54 so old. 16:04:55 I know it seems like old news, being a WHOLE WEEK AGO 16:05:14 But reviews have been *really* good relative to most other releases 16:05:47 #info F21 Workstation is out, it's awesome, and congrats to everyone. That is all. 16:06:09 So moving on... 16:06:12 #topic Change proposals 16:06:19 #url http://fedoraproject.org/wiki/Workstation/Tasklist 16:07:15 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 I'll file at least the gnome-shell and nautilus ones, when the first chunks of that work land upstream 16:08:27 #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 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 mclasen: Yeah, I'm gone after this Friday 2014-Dec-19, until Monday 2015-Jan-05 16:10:09 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 therefore I'd rather wait until january 16:11:00 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 sounds right 16:11:19 Or maybe just make that the point where we start rounding up what needs to be filed :-) 16:11:35 maybe related to change requests - does the schedule currently look like it'll fit gnome 3.16 ? 16:11:45 #action mclasen file gnome-shell + nautilus related changes 16:12:16 #action stickster Put remaining Change items on agenda for 2015-Jan-07 to check outlook for landing 16:12:34 yes, we have plenty of time to get gnome 3.16 in 16:12:52 F22 final freeze is currently schedule for not earlier than 2015-05-05 16:13:06 and 3.16.1 is 2015-04-13 16:13:35 looks like the usual tight fit, ok 16:14:15 Yeah, currently it looks like the way the schedule meets up, we'd have stable in for beta freeze (barely) 16:14:47 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 stickster jinxed it now 16:15:24 #info Current GNOME 3.16 schedule looks like a tight but workable fit for current Fedora 22 proposed schedule 16:15:27 let me know if you'd need anything regarding changes 16:15:30 rdieter: D'OH! 16:16:38 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 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 that would be nice, certainly 16:19:45 But it seems to me we might also have specific things to improve/create with a top-down focus as well 16:21:37 That seems like something WG folks can effectively discuss/collaborate on to improve the Workstation over a release or two 16:22:21 ryanlerch mentioned something on list yesterday about upgrade notifications, for example 16:22:46 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 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 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 Wow. That was a very long sentence. 16:24:20 most of the tasks on the task list are more or less in support of one of those 16:25:22 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 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 I'll note that my big-picture item list misses anything developer-specific, really 16:26:22 wayland is a bit more manageable/self-contained 16:26:30 as is the QT integration 16:26:33 jwb: That's a good point 16:26:42 that is very true 16:26:50 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 #info jwb points out that some upstream stuff will require Fedora-specific work outside the WG, e.g. app bundles 16:27:12 alex is giving a talk at devconf about his app bundle work 16:27:35 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 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 and of course kind of the kicker here: will FESCo/Council sign off on this within Fedora? 16:28:29 i'd love to see alex's talk. i'll make it a priority 16:28:32 Is this https://people.gnome.org/~alexl/glick2/ ? Or has that moved on a bunch? 16:28:34 there's several things, I can go and dig a bit 16:28:39 also, and what is the net benefit to our end users? 16:28:47 glick and glick2 were earlier attempts 16:28:53 ryanlerch, yes! 16:28:54 the current work is based on ostree 16:29:20 i think app bundles will be beneficial for a number of reasons, but i don't want a repeat of SCLs 16:29:33 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 jwb: +100 16:29:45 and i kind of think the benefits aren't for _fedora_, but more for end users/developers 16:29:51 and fedora benefits indirectly 16:29:56 which is sometimes a hard sell 16:30:15 ryanlerch: the end goal would be that 3rd parties can provide app bundles that can run across distros 16:30:16 ironic, since you'd think "make something great and people will think you're great" would be an easy sell 16:30:38 stickster, depends on who's doing the making 16:30:43 ryanlerch: you can probably see already where this might cause some headscratching in a packager world... 16:31:12 mclasen, yeah :) 16:31:33 jwb: Good point. Let's adopt a lovable mascot 16:32:44 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 stickster, +1 for Mogwai to be our new mascot then :) 16:32:57 oh my 16:33:01 cschalle_: You know what happens when you feed them after midnight 16:33:08 or get water on them 16:33:25 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 mclasen, like firefox? 16:34:05 jwb: Ooo, that's an interesting one. 16:34:06 cschalle loves the idea that mozilla might ship an app bundle to get us out of being the middle man 16:34:24 I do :) 16:34:38 So I seem to have taken us far afield of the topic :-) I do that sometimes. 16:34:41 so... just to get this out of the way. these bundles should be consumable on a wide variety of platforms, right? 16:35:04 like... firefox 456 bundle that runs on fedora, rhel, centos, etc 16:35:20 ideally yes 16:35:25 that is one of the points, yes. that is the incentive for 3rd parties to use them 16:35:44 so offering infrastructure for 3rd parties to use to _create_ those bundles might be a good approach 16:36:07 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 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 (*no guarantee it will run everywhere) 16:37:25 :-) 16:37:34 Wait, we're not talking about NIH'ing OBS? 16:37:43 I need to catch up with alex anyway, I'll see if he has any thoughts on tooling 16:37:59 being fair, i don't think we care if bundles run on fedora and gentoo. 16:38:35 most 3rd parties will care if they run on ubuntu... 16:38:49 yes 16:38:53 which is a bit of a sore point, since they go their own way with click... 16:39:07 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 well, we've got similar issues with docker/rocket too 16:39:22 having a tool to convert to click isn't a terrible idea 16:39:31 but that means we have to have something to convert _from_ already ;) 16:39:41 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 if thats feasible (conversion), sure. I'll ask alex 16:40:03 ryanlerch, well, maybe. colin thinks containerized desktop apps are very hard to do because of all the ipc 16:40:16 but yes, i think that's probably a goal here 16:40:32 stickster, yes 16:41:02 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 sure, we can move on 16:41:24 of course, the notification won't do much good unless the upgrade works flawlessly in almost all situations 16:42:19 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 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 kalev: Right. And we'd probably want to solve this in a way that worked across the offerings 16:43:32 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 kalev, won't the upgrade GUI pretty much just be a button to start it? 16:44:42 mclasen: it actually uses a different systemd target than the packagekit offline updater 16:44:58 sure, but its still the same mechanism, basically 16:45:04 anyway, lets take the details out of this meeting 16:45:16 I'll inquire if we have mockups for the ui portion of this 16:45:25 #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 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 #action mclasen dig up summary/details on current app bundles effort so we can understand state upstream 16:46:34 i look forward to the "privacy" concerns coming from finding out if there's an upgrade available. 16:46:34 #action mclasen look for mockups for UI portion of upgrade notification (possibly execution?) 16:46:42 jwb: AS DO I 16:46:58 jwb: also the Privacy Spin 16:47:32 Clearly this will be some great discussion for us in January, though. Seriously. 16:47:45 fyi, here is a different take on 'system upgrade': https://wiki.gnome.org/Design/OS/Migration 16:48:18 #info For reference, a different implementation of upgrades: https://wiki.gnome.org/Design/OS/Migration 16:48:31 that... doesn't look like upgrade 16:48:42 thats why I said 'different take' 16:49:08 well, it would be if you could apply it to a single machine without having to do a fresh install :) 16:49:21 *nod 16:49:24 * stickster is going to move on so we can at least hit one more thing before break 16:49:32 #topic Resolving firewall question 16:49:32 in-place upgrades are always problematic - if you could conveniently save and restore all your data, you can avoid it... 16:49:35 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 yeah, lets move on 16:50:24 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 yes 16:50:52 mitr asked FESCo to hold off on deciding anything 16:50:57 Do we have any consensus in the WG about our ideal desired state for the Fedora firewall "experience"? 16:51:37 stickster, is this the open ports thing? 16:51:52 yes 16:51:56 I think my 'rule of thumb' is that applications breaking 'silently' is an absolute no 16:52:00 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 how exactly that's implemented, that's probably secondary 16:52:27 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 ryanlerch: I have barely more, I've got your back :-) 16:53:14 mclasen, even in today's world of RPMs, that can still apply. you install the package, you grant network access. 16:53:40 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 stickster, i think mclasen meant it was implicit upon install 16:54:25 "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 (or in our existing case it will just work anyway) 16:54:40 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 right 16:54:53 and the big problem with all these approaches is dynamic ports 16:55:01 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 mclasen++ -- it's more like a question for the app overall 16:55:26 cschalle_, won't 95% of people just blindly click yes? 16:55:31 would messageing help here? when i install a package that opens a port it tells me that? 16:55:44 jwb, sure, but 95% of people just disable their firewall today so no net loss ;) 16:55:47 jwb: /me is the first to raise his hand and say he does this on Android ALL THE TIME 16:56:08 cschalle_, i agree, but it's actually more work and hassle for the user than what we have right now 16:56:19 maybe that's the compromise though 16:56:21 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 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 mclasen: More like "is it ok for app X to be on the network?" or something 16:56:44 but ask about a concrete thing: 'are you comfortable sharing your vacation photos on this network ?' 16:57:05 ! 16:57:08 * rdieter thinks signed/trusted packages should 'just work' too, if that means automatically opening ports, so be it. 16:57:27 rdieter: Good point -- there is a packager trust level here, too 16:57:38 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 rdieter: Although the automatic opening itself may be problematic when they're dynamic 16:58:07 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 ..which I guess is a good thing; applications from the wild shouldn't be trusted to behave 16:58:29 Like all signed/trusted packages are in a specific context that's OK for high port access 16:58:41 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 else its game over 16:58:50 * stickster quickly stops thinking implementation, before he hurts himself 16:59:21 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 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 sorry, 1 minute. 16:59:52 ryanlerch: I didn't get to the triage question, but will carry it over 16:59:54 * randomuser 16:59:55 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 ^ this, right. 17:00:44 sure - I'm just thinking about the layer of protection for unintentional behaviors 17:00:56 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 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 agh, we're overtime. 17:01:43 Is the above a good way to describe something actionable we can work on after holiday? 17:01:50 +1 17:01:53 For today's FESCo meeting, where firewall is on the agenda, what is the plan? Ask for delay? 17:02:12 probably 17:02:18 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 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 I'll be there anyway, to answer questions 17:03:10 fesco meeting is an hour from now ? 17:03:14 yes 17:03:14 Also, it should be OK for WS/Server/Cloud to be different in this regard, because of different user expectations. 17:03:17 mclasen: Correct. 17:03:38 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 #action stickster mclasen be around for FESCo meeting in ~1 hour if this topic comes up 17:04:09 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 mclasen: +1 17:05:07 #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 OK, 5 min over, sorry guys. Anything else before we adjourn? 17:05:28 #topic All other business 17:05:36 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 #action stickster Carry over bug triage topic for next meeting 17:06:13 mcatanzaro: I'm not sure that's in question. FESCo formed the WGs. 17:07:04 Let's take that to #fedora-workstation if needed though, we're past time here... 17:07:08 closing in 10 17:07:13 mcatanzaro, it's not. WGs report to FESCo. 17:07:15 5 17:07:25 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 #endmeeting