14:00:27 <mclasen> #startmeeting Workstation WG
14:00:27 <zodbot> Meeting started Wed Aug 19 14:00:27 2015 UTC.  The chair is mclasen. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:27 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:00:40 <mclasen> #meetingname workstation
14:00:40 <zodbot> The meeting name has been set to 'workstation'
14:00:50 <mclasen> #topic Roll call
14:01:09 * kalev waves.
14:01:09 <mclasen> hi everybody, I'll be your lovely replacement chair today
14:01:17 <mclasen> bear with me as I fiddle with the bot
14:02:12 <mclasen> whose around ? cschalle, kalev, do we have owen ?
14:02:20 <cschalle> I am
14:02:28 <kalev> I am too!
14:03:42 <mclasen> I don't see either owen or mcatanzaro, we need a few more people for quorum, I think
14:06:28 <mclasen> I can't see owen or mcatanzaro on other networks either
14:06:38 <mclasen> who else are we missing ?
14:06:42 <sgallagh> /me lurks in case the meeting happens
14:06:53 <mclasen> stickster is excused, of course
14:07:16 <otaylor> Sorry to be late!
14:07:38 <mclasen> do I need to use some command to update the attendee list ?
14:08:04 <kalev> rdieter is missing too
14:08:19 <kalev> I've seen stickster use #char command
14:08:31 <kalev> #chair, even
14:08:34 <mclasen> #chair mclasen, cschalle, kalev, otaylor
14:08:34 <zodbot> Current chairs: cschalle kalev mclasen otaylor
14:08:44 <mclasen> thanks, kalev
14:08:46 <rdieter> sorry, I missed the time/date change on my calender, here
14:08:52 <mclasen> #chair rdieter
14:08:52 <zodbot> Current chairs: cschalle kalev mclasen otaylor rdieter
14:09:04 * nirik is lurking in the back. waves to all the workstation folks.
14:09:15 <mclasen> with that, I believe we have quorum
14:09:29 <sgallagh> The chair command lists the people that zodbot will listen to for commands like #info
14:09:46 <mclasen> welcome again, we've been slacking off on having these meetings for a while, so lets make this a good one
14:10:16 <mclasen> stickster did send a list of agenda items on monday, do we have any additions for that ?
14:10:43 <kalev> I have two things to add
14:11:38 <kalev> one is the discussion about moving i686 to a second class citizen
14:11:38 <rdieter> mclasen: can you give a brief update on rpm file triggers
14:11:51 <mclasen> kalev: whats the other one ?
14:11:55 <mclasen> rdieter: sure, I will
14:12:11 <kalev> the other one is whether to switch to gnome-characters
14:12:23 <mclasen> good point, I'll add these to the agenda
14:12:33 <mclasen> so, then
14:12:42 <mclasen> #topic Possible critical GLib issue?
14:12:50 <mclasen> I'll report on this one
14:13:16 <mclasen> early in the 2.45 cycle, the file monitoring in glib has been significantly rewritten
14:13:42 <mclasen> and since then, a number of bugs have appeared where things 'mysteriously' fail
14:14:03 <mclasen> like deleted users not disappearing or timezone updates not applying and so on
14:14:24 <mclasen> this has by now been more or less confirmed to be fallout from the file monitor rewrite
14:14:52 <mclasen> unfortunately, desrt who did the rewrite has been pretty much unavailable in recent months, so we were slow in getting this looked at
14:15:03 <mclasen> I sat down last night and started to track it down
14:15:21 <mclasen> I think I've understood whats going wrong, and I am pretty close to having a working fix
14:15:57 <mclasen> so, thats my status update - any questions on that ?
14:16:20 <kalev> thanks for looking at that!
14:16:20 <mclasen> I'll ask kalev and a few others to test my fix once I am confident it works
14:16:37 <mclasen> I'm also writing testcases for glib file monitoring api as part of this
14:17:24 <mclasen> #action mclasen to come up with a working fix for glib file monitoring
14:17:46 <mclasen> ok, lets move on then
14:18:14 <mclasen> #topic rpm-ostree based Workstation - are we going to line this up for a f24 chnge ?
14:18:45 <otaylor> So, for starters, we definitely wouldn't propose switching the default for f24 - we're definitely not going to be ready for that
14:19:13 <mclasen> true
14:19:32 <mclasen> what are the next steps to get this underway ?
14:19:33 <kalev> we could, perhaps, produce a side image based on rpm-ostree where we can see how things work out, but not advertise it in any capacity? basically just for our own testing?
14:19:36 <otaylor> So what would be under discussion for f24 would be an official build artificat
14:20:11 <otaylor> I think most of what we need to do to make it real is actually other work we are doing - xdg-app and wayland work
14:20:21 <mclasen> I've been thinking we should have a hangout with adam miller - he seemed very eager to help with this, in his flock presentation
14:20:38 <otaylor> mclasen: sounds like a good idea in terms of what we need to do to start building workstation ostrees
14:21:11 <mclasen> do you want to take the task and invite adam to a planning session ?
14:21:44 <otaylor> need to do some planning with hughsie too to figure out what needs to be done to have updates
14:21:55 <mclasen> good point
14:22:36 <mclasen> #action otaylor reach out to Adam Miller and Richard Hughes to discuss workstation ostrees and updates
14:22:48 <otaylor> mclasen: will do
14:23:14 <mclasen> anything more on atomic workstation ?
14:23:40 <otaylor> do we generally think that we'l have a working xdg-app ecosystem for f24?
14:24:43 <mclasen> I've just talked to hughsie about making xdg-apps show up in gnome-software for f24, which is one of the important steps towards that
14:24:48 <otaylor> the developer side is still a separate bundle of stuff to unsort, but having people able to install "most" apps seems like a prerequisite for saying that it's a f24 feature
14:25:37 <cschalle> but having the core build would be a useful testing tool and proof of concept even if we only have a few xdg-apps ready?
14:26:09 <mclasen> in the short term (next month), I expect us to have xdg-app bundles of 'nightlies' available for some prominent apps
14:26:37 <otaylor> cschalle: yes - but that's something different than what we want to offer as an official way to install fedora
14:26:47 <cschalle> agreed
14:27:30 <mclasen> the bigger question is to what extent we want to use xdg-app for apps that are currently available as rpms in fedora
14:28:00 <otaylor> mclasen: well, for atomic workstation, we need to do that - possibly by auto-converting rpms
14:28:23 <otaylor> but such apps probably can't be sandboxed
14:28:43 <mclasen> so, thats probably something we need to investigate. I'll have to find somebody with capacity for that
14:28:50 <mclasen> and yes, those wouldn't be sandboxed
14:29:26 <otaylor> so we are in the case where there are "safe apps" and apps where you trust the provider
14:29:50 <mclasen> basically, yes
14:30:09 <otaylor> (with the caveat that a safe app can still use your computer as a botnet node)
14:30:25 <mclasen> #action mclasen find resources to investigate automatic rpm -> xdg-app conversion
14:30:29 <rdieter> silly question (may show some ignorance about os-tree): can usual rpm-based apps be installed on top of a os-tree base system?
14:31:13 <mclasen> rdieter: the atomic team has been working towards it - in the 'pure' original ostree model, you can't
14:31:35 <otaylor> rdieter: "sort of" - basically the plan is that you can create a local ostree that layers additional rpms on top of what is shipped
14:31:37 <rdieter> ok, allowing that would make the transition eaiser
14:32:05 <rdieter> thanks
14:32:20 <otaylor> rdieter: if the local ostree changes in any way other than strict file addition, you need to reboot. Even installing a package often changes files(icon caches, etc.) on the system
14:32:35 <rdieter> <nod>
14:32:37 <kalev> yep, if we had that then we wouldn't need to get everything converted to xdg-app at the same time as the switch to an atomic base image
14:33:38 <otaylor> rdieter: also, you can have the case where upgrading the local ostree fails (package dependencies, etc.) so it breaks the idea that you can always seamlessly roll forward or back to a tested OS
14:34:09 <mclasen> isn't rolling _back_ still save?
14:34:29 <mclasen> I guess you have to roll back all layers at the same time
14:35:05 <otaylor> mclasen: well, you can always roll back to something you were using before. If you want to redo the local layering with later additions that might not work.
14:35:15 <rdieter> ok, I just had the naive notion of a base platform that could be os-tree based, with leaf (rpm or xdg-app) apps on top of that
14:36:17 <otaylor> rdieter: xdg-apps and containerized server apps definitely work, but you need a pretty strong OS/app isolation system and rpm doesn't provide that in itself
14:36:57 <mclasen> anything else on rpm-ostree at this point ? I think we have the next steps lined up now
14:36:59 <rdieter> otaylor: <nod>, I assumed some sort of isolation was needed in that case, thanks
14:37:12 <mclasen> not sure we really answered the "are we doing this for f24?" question
14:37:16 <otaylor> rdieter: (you could stick a docker container or a xdg-app or even a binary with minimal dependencies *inside* an rpm - and you'd be fine,)
14:37:27 * otaylor stops so we can move along
14:37:54 <mclasen> ok, switching to todays agenda additions
14:37:56 <otaylor> mclasen: I think we might have to plan now to get as far as we can, and decide later whether it's a preview or a feature
14:38:18 <mclasen> sounds right to me
14:38:30 <mclasen> #topic i686 demotion
14:38:40 <mclasen> kalev, you wanted to talk about this ?
14:39:07 <kalev> so, the kernel team said that they are no longer interested in i686
14:39:31 <kalev> and I am not sure it makes sense to ship iso images for a platform that the kernel team doesn't want to support
14:40:00 <kalev> I think we have two options here: one is two stop producing workstation i686 image. The other is to somehow get the kernel team to continue supporting i686.
14:40:16 <kalev> I don't think anything in between makes sense - such as producing an image with a kernel that is unsupported
14:40:29 <sgallagh> The Server SIG also asserted yesterday that as of F24, we don't want to produce i686 media either.
14:40:32 <otaylor> or a image with a x86_64 kernel and 32-bit userspace?
14:40:47 <mclasen> does that run on a 32bit machine ?
14:41:18 <otaylor> Other than quite old hardware, the other case for 32-bit userspace is small memory machines and VMs
14:41:22 <sgallagh> otaylor: The main reason we produce i686 media today is to support the few remaining machines that don't have x86_64 support
14:41:27 <sgallagh> Such as older Atom processors
14:42:10 <otaylor> for the workstation, at 2GB 32-bit is significantly better than 64-bit. At 4GB and up, it's not important
14:42:22 <sgallagh> Those latter cases seem like a better argument for Cloud than Workstation
14:42:56 <sgallagh> Workstation is barely functional at 2GB on any arch
14:43:10 <sgallagh> (once you load a browser and a mail client, all the memory is pretty much accounted for)
14:43:10 <otaylor> sgallagh: there's a lot more OS overhead for workstation, so the breakpoint is smaller
14:43:25 <otaylor> sgallagh: well, yes, firefox+evolution isn't workable in 2GB on any arch
14:43:38 <mclasen> sad, but true
14:43:47 <kalev> and those are the programs we ship in workstation
14:43:57 <kalev> in the default install
14:44:18 <sgallagh> I'd make the argument that we should really declare a 4GB minimum for Workstation, which puts us back to no real advantage on 32-bit
14:44:34 <sgallagh> s/minimum/recommended/ at least
14:44:46 <mclasen> whats the competitive landscape - do ubuntu, suse, mandriva ship i686 images ?
14:44:51 <otaylor> When I was helping people gettin starting with gnome development in a fedora vm on their existing windows/mac machine, 32-bit was a big help, but I don't think that's a very typical use case fr fedoa
14:45:00 <mclasen> rhel is 64bit only, if that matters
14:45:21 <rdieter> wouldn't hurt my feelings to see i686 go away either, several items in Qt5 stack ideally need sse2... and current packaging involves hacks to support non-sse2 on i686 too
14:45:22 <sgallagh> mclasen: Ubuntu ships 32-bit but clearly states it's only for machines with  < 2GB RAM
14:46:20 <sgallagh> (FWIW, Unity doesn't run any better than GNOME 3 with that little memory)
14:46:35 <mclasen> opensuse has "Legacy 32bit pc" as a choice
14:46:43 <otaylor> I think I'd be OK dropping 32-bit in that people testing fedora workstation in a 2GB vm don't get a *good* experience even with 32-bit, to simplify the testing matrix and concentrate on where we can provide a good experience
14:46:48 <kalev> anyway, I would personally want to have the kernel team support i686 kernels for F23 Workstation - do we have leverage to get them to do that?
14:46:52 <kalev> and then possibly drop the i686 iso image altogether for F24, alongside with the Server - this should leave enough time for people to plan how to migrate to x86_64
14:47:21 <mclasen> "support" is of course a very relative term in fedora land
14:47:46 <sgallagh> Maybe we could let the XFCE spin deal with low-resource users
14:48:17 <mclasen> doesn't help for not letting users run an 'unsupported' kernel
14:48:42 <mclasen> unless you think a 64bit xfce would be better on resources
14:48:54 <otaylor> I need to leave now, I'm +1 for either dropping i686 iso for either f23 or f24 depending on what people is better
14:48:54 <mclasen> which I doubt, considering that we were talking about ff and evo as hogs
14:49:13 <mclasen> thanks, owen
14:49:58 <kalev> I'll note that this is also on fesco's agenda for today's meeting
14:50:06 <mclasen> should we vote on this ? what are the options ?
14:50:07 <sgallagh> In Server, we figured it's too late for F23, since we're post-alpha.
14:50:15 <sgallagh> I'd recommend the same to Workstation, just for consistency.
14:50:33 <kalev> I think we can split this into two decisions:
14:50:38 <kalev> 1) what to do for F23
14:50:39 <mclasen> sgallagh: to clarify, you decided to have i686 for f23 or to not have it ?
14:50:42 <kalev> 2) what to do for F24+ :)
14:51:05 <sgallagh> mclasen: We had it in Alpha, so we're keeping it for F23. We're dropping i686 for F24.
14:51:14 <mclasen> I see
14:51:15 <Southern_Gentlem> I think it should be a feautre request for f24 to drip 32bit (but i know i have 32bit machines still running)
14:51:33 <sgallagh> Yeah, I'd make an argument that this is a definite candidate for a Change Proposal
14:51:39 <sgallagh> /me makes a note to write one for Server
14:51:52 <mclasen> so, lets make a decision on f23 first
14:52:11 <mclasen> suggestion: follow the server wg and keep i686 for f23
14:52:28 * mclasen not sure if he needs to tell the bot about this being voted on or not
14:52:52 <mclasen> anybody in favor of my suggestion ?
14:53:07 <kalev> I think it's a good plan
14:53:31 <rdieter> mclasen: +1
14:54:01 <mclasen> including myself and owen, I see 4 in favor so far - cschalle, how about you ?
14:55:09 <cschalle> +1
14:55:12 <sgallagh> mclasen: (RE bot: Some groups use #idea for indicating vote-eligible items, but it's not mandatory. Do use #agreed once a vote concludes, though)
14:55:12 <mclasen> thanks
14:55:34 <mclasen> #agreed We will keep the i686 workstation image for f23
14:56:12 <mclasen> do we have a suggestion for f24 vs i686 at this point, or do we defer this until fesco has talked about it ?
14:56:23 <kalev> let's defer and see what they say
14:56:47 <sgallagh> If you have a recommendation, please make it
14:56:57 <sgallagh> FESCo will be making its decision at least in part based on the WG wishes.
14:57:43 <sgallagh> (Even if that recommendation is "we'll abide by however FESCo wants to do it", that's useful information.)
14:58:13 <mclasen> my recommendation is to keep it if we can ensure it is 'supported' - either by the kernel team or a community group
14:58:13 <sgallagh> i.e. FESCo doesn't want to make a decision and then hear you guys say "well, we really wanted it to go the other way"
14:58:29 <mclasen> and to drop it if that is not the case
14:58:43 <kalev> yes, that's what I am thinking as well
14:59:07 <mclasen> ok, we have 2 minutes for the last  2 topics
14:59:12 <mclasen> lets make this quick
14:59:21 <sgallagh> Fair to phrase that as "The Workstation WG would prefer to keep i686 if and only if someone is actively maintaining the kernel, otherwise they will drop it"?
14:59:42 <mclasen> #info The Workstation WG would prefer to keep i686 if and only if someone is actively maintaining the kernel, otherwise they will drop it
14:59:47 <sgallagh> Thanks.
14:59:52 <sgallagh> /me will report that to FESCo
14:59:55 <mclasen> #topic gnome-characters to replace gucharmap ?
15:00:08 <mclasen> kalev, want to say why its a good idea ?
15:00:24 * mclasen wonders if we are getting kicked out here at 11 (ie now)
15:00:31 <kalev> gnome-characters seems to be the one getting a lot of attention upstream and gucharmap isn't any more
15:00:41 <kalev> and aday said that he thinks we should do the switch
15:00:48 <mclasen> ok
15:00:57 <mclasen> few more points: gnome-characters has gnome-shell search integration
15:01:03 <mclasen> and a much nicer in-app search
15:01:08 <kalev> otherwise, I don't really use it myself so I am not in a good position to judge the quality of the apps - just going with aday's recommendation here
15:01:10 <mclasen> gucharmap shows more obscure unicode data
15:01:27 <mclasen> and upstream recommends the switch now, as you said
15:01:33 <mclasen> so, lets just vote on this
15:01:45 <aday__> i'm here if anyone has questions
15:01:47 <mclasen> #idea: replace gucharmap with gnome-characters in f23
15:01:53 <mclasen> I am +1 on this
15:02:16 <kalev> +1
15:03:05 <mclasen> owen left - cschaller, rdieter, do you have an opinion on this ?
15:03:30 * mclasen pushing to end the meeting on time
15:03:35 <rdieter> i defer to your opinions, if you all think it good idea, then +1
15:03:59 <mclasen> kalev: will you do the legwork to make the switch happen, if we get cschalle's vote ?
15:04:05 <kalev> sure, I'll do it
15:04:49 <mclasen> cschalle: last call
15:06:41 * mclasen lets the clock run out on cschalle
15:07:01 <cschalle> +1
15:07:09 <cschalle> sorry, being pulled in multiple directions here
15:07:10 <mclasen> #agreed gnome-characters will replace gucharmap in f23
15:07:24 <mclasen> #action kalev replace gucharmap by gnome-characters
15:07:33 <mclasen> ok, with that, lets close it. thanks everybody
15:07:37 <mclasen> #endmeeting