15:01:32 <stickster> #startmeeting Workstation WG
15:01:32 <zodbot> Meeting started Wed Jan 20 15:01:32 2016 UTC.  The chair is stickster. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:32 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:01:32 <zodbot> The meeting name has been set to 'workstation_wg'
15:01:35 <stickster> #meetingname workstation
15:01:35 <zodbot> The meeting name has been set to 'workstation'
15:01:38 <stickster> #topic Roll call
15:01:40 <stickster> .hello pfrields
15:01:41 <zodbot> stickster: pfrields 'Paul W. Frields' <stickster@gmail.com>
15:01:50 * kalev appears in a puff of magic.
15:02:32 <mcatanzaro> Hi
15:02:32 * mclasen___ waves
15:06:06 <stickster> #chair kalev mcatanzaro mclasen___
15:06:06 <zodbot> Current chairs: kalev mcatanzaro mclasen___ stickster
15:06:24 <stickster> Sorry guys, was handling another problem and now I'm here 100% :-)  Has anyone seen cschaller?
15:06:31 <mclasen___> grr
15:06:43 * mclasen___ *still* gets sporadic sigbus under wayland
15:07:10 <mclasen___> I saw him this morning
15:07:16 <mclasen___> and I reminded him of this meeting
15:07:31 <stickster> OK. We'll forge ahead.
15:07:50 <stickster> #topic i686 Workstation images
15:08:43 <stickster> Hey leguin, stop messing up our topic
15:08:46 <stickster> #topic i686 Workstation images
15:09:11 <stickster> So in summary -- it looks like ~20% historically (maybe less currently, but not a *lot* less) of our downloads are 32-bit currently. I had hoped it was a lot less, which would make it more obvious to stop producing 32-bit images. Doesn't seem so clear cut now.
15:11:34 <mclasen___> no, not very clear cut
15:11:54 <stickster> I think jwboyer mentioned that other hypervisor products often use 32-bit downloads
15:12:00 <mclasen___> why are we eager to drop it ? lets qa targets ? one less links on the download page ?
15:12:37 <kalev> because the kernel team stated that they don't want put time into fixing 32 bit issues
15:12:46 <stickster> mclasen___: General unease with sending out something as an official release which isn't getting as much coverage for general testing, kernel attention, or blocker status
15:13:06 <stickster> kalev: don't want, and logistically can't in many cases
15:13:36 <kalev> and we might end up with a release where we have a solid release, and then since the kernel team doesn't view 32 bit as a primary deliverable, a kernelk update breaks all 32 bit installations for example
15:14:36 <mclasen___> so this is a request from the kernel team then - why should we support it if it cuts off 20% of our user base ?
15:14:40 <stickster> Right -- and since FESCo agreed Fedora doesn't block the release on i686, that release could still go out -- rel-eng produces things through an automated process and it's not easy (maybe not feasible?) to somehow hold those back
15:15:41 <stickster> mclasen___: Because we don't know where that 15-20% comes from. It's not clear whether it's really native hardware, or a case where users could feasibly use the 64-bit release if they knew
15:15:57 <stickster> Hooray for not being able to do information gathering due to privacy concerns
15:17:11 <kalev> I think we can say with quite high confidence that GNOME doesn't really run well on 32-bit only machines
15:17:19 <kalev> but that doesn't mean that people aren't running 32 bit installations on 64 bit capable hosts, just to save RAM for example
15:17:54 <kalev> while they could switch such installations to 64 bit, it's probably a lot of pain if suddenly apps starts requiring, let's say 40% more RAM
15:18:18 <stickster> kalev: I just looked at a graph that smooge sent earlier... for Workstation, 32-bit is actually a bit under 10%
15:18:26 <kalev> ahh, excellent
15:18:44 <mcatanzaro> To be clear, no matter what, the kernel team already does not fix 32-bit issues anymore. That's not going to change unless RH wants to invest in it.
15:18:59 * mclasen___ doesn't really know a good reason for why GNOME shouldn't run fine in 32 bits
15:19:18 <stickster> mcatanzaro: Correct. And since RHEL only comes in x86_64 nowadays, it doesn't seem likely
15:19:29 <kalev> I don't have a strong opinion either way whether we should ship 32 bit image, but if we DO ship it, I think we should make sure that the kernel there is supported
15:19:54 <stickster> kalev: That's a good statement to make. It also argues directly for not shipping. :-)
15:20:18 <mclasen___> in fact, endless ships a product with GNOME on 32bit arm machines, and it runs just fine
15:20:19 <kalev> mclasen___: I was trying to say that older, 10 year old machines that don't have the 64 bit instruction set are probably too old hardware wise anyway, lacking sufficient opengl support etc
15:20:20 <mcatanzaro> kalev++
15:21:00 <mcatanzaro> mclasen___: EndlessOS runs great on very low-end 32-bit processors and ARM as well.
15:21:05 <mclasen___> or was shipping, at least
15:21:17 <mclasen___> newer machines may be 64bit now
15:21:23 <Southern_Gentlem> kalev,  but yet in some of the third world countries that is the stateo of the art hardware
15:21:25 <mcatanzaro> But upstream GNOME probably stresses the hardware rather more
15:21:48 <stickster> I personally don't feel it behooves us to ship something that's not getting sufficient support. Furthermore, there are alternatives, even in the Fedora universe, for people with older machines with restricted capabilities, that don't carry the expectation of support.
15:24:12 <stickster> Most of the work going on that affects Workstation, AIUI, is targeted at making sure modern hardware works well (of course trying to avoid regressions, but there's only so much upstream can do for ancient stuff)
15:26:13 <stickster> "don't make promises you can't keep" mantra
15:26:58 * stickster looks to kalev mcatanzaro mclasen___ rdieter_ for some argument or agreement
15:27:05 * mcatanzaro shrugs
15:27:18 <mclasen___> I don't know
15:27:33 <otaylor> (/me is also here, but shrugs)
15:27:34 <mclasen___> it seems odd to do so much hand wringing about support in an unsupported OS
15:27:54 <mclasen___> "nobody has a support contract for fedora"
15:28:03 <stickster> otaylor: I didn't see you, sorry!
15:28:05 <stickster> #chair otaylor
15:28:05 <zodbot> Current chairs: kalev mcatanzaro mclasen___ otaylor stickster
15:28:12 <stickster> Great, now we can actually make a decision :-)
15:28:21 <otaylor> stickster: My "here!" was eaten by a netsplit
15:28:50 <mcatanzaro> Since nobody seems to care, maybe we should just continue with the status quo.
15:29:07 <stickster> mclasen___: You do make a good point. But there's no way to make the finer point with our userbase -- they have no way of knowing how we consider/treat e.g. i686 kernel bugs
15:29:40 <stickster> well, maybe not entirely true... we could put together a bit more info in a Fedora Magazine article, or the release announcement, or s/th else.
15:30:02 <kalev> a argument against dropping i686 is that if we drop i686 workstation, at the same time other i686 spins are still going to be available for download
15:30:08 <kalev> so users who would normally go for i686 workstation because of hardware limitations are going to be forced to use the $other_spin
15:30:33 <kalev> while in practice, all the polish work that goes into workstation would probably mean that i686 workstation works better than i686 $other_spin, even though we don't put any resources into i686 workstation
15:30:45 <stickster> mcatanzaro: I have a strong opinion to the extent I don't want a misunderstanding of what the Fedora kernel team is going to handle
15:30:49 <kalev> the kernel is still going to be the same, no matter if they choose workstation or @other_spin
15:30:57 <mclasen___> fand they're getting the same 'garantees' with $other_spin
15:31:31 <otaylor> If the machien *can't* run 64-bit, it's old enough that they might be better offer with a non-composited desktop
15:31:51 <otaylor> If the machine *can* run 64-bit, you'd think they wouldn't switch spins because of 32-bit vs. 64-bit.
15:32:20 <otaylor> I think it's all about memory saving and only about memory saving, mostly with respect to vms.
15:33:20 * kalev nods.
15:33:22 <mcatanzaro> "If the machien *can't* run 64-bit, it's old enough that they might be better offer with a non-composited desktop" <-- This seems convincing to me.
15:34:42 <mcatanzaro> "I think it's all about memory saving and only about memory saving, mostly with respect to vms." <-- This use case is best served by a 64-bit kernel with 32-bit userspace (so kernel maintenance is not really relevant) and AFAIK we have never done that.
15:36:22 <stickster> To be fair, dropping i686 WS images doesn't really solve the whole problem; only dropping i686 as a primary arch does that AFAICT, which is not our call here.
15:36:53 <mclasen___> do we need to vote on anything here ? or should we just move on ?
15:37:07 <stickster> mclasen___: We need to vote on whether to drop the i686 imags.
15:37:07 <mclasen___> I could get behind a statement like "we only want to ship images with a supported kernel"
15:37:41 <jwb> the tentative question becomes "are the WG members OK shipping an image that nobody tests and is not going to block the release?"
15:37:54 <stickster> mclasen___: Then to the extent that we have a supported kernel, that would mean not shipping i686.
15:38:26 <jwb> where "nobody" might not literally translate to nobody, but is most likely accurate among the set of people working _on_ Workstation
15:40:09 <mclasen___> I could give different answers to the two parts of that question
15:40:17 <mclasen___> I'm ok with shipping an image that doesn't block the release, certainly
15:40:27 <mclasen___> as long as we only ship it in good shape...
15:40:39 <jwb> that requires someone to test it
15:40:43 <mclasen___> right
15:40:57 <mclasen___> that is why I have a different answer to the first part of your question
15:41:04 <mcatanzaro> mclasen___: By definition, "doesn't block the release" means "may ship in bad shape."
15:41:31 <mcatanzaro> Well, that's the Fedora definition at least... theoretically we could decide last-minute to not do a 32-bit release....
15:41:31 <jwb> QA seemed to indicate it would get tested in some fashion if it existed.  so the WG needs to decide if that somewhat nebulous definition of tested is good enough
15:41:49 * stickster feels like QA had an out there, but didn't take it
15:42:29 <stickster> mcatanzaro: Of course that would look quite bad, as opposed to an up front announcement/commitment
15:43:05 <mclasen___> mcatanzaro: my assumption was that the alternative to "block the release" is "drop if it fails testing"
15:43:37 <jwb> that requires hacks from rel-eng for last minute stuff.  they hate that
15:43:40 <mclasen___> anyway, we've quibbled with definitions for long enough
15:43:47 <stickster> mclasen___: that is do-able. It might, however, cause dgilmore and the rel-eng team some scramble if that comes very late. I don't know how complex it is to drop an arch from compose.
15:43:50 <mclasen___> they hate everything
15:44:29 <stickster> Well in summary, I don't think we have a consensus, and without that, it's status quo for now :-\
15:45:40 <mcatanzaro> stickster: I don't see any real opposition to dropping the images, I think the general consensus is "meh"
15:45:48 <mcatanzaro> Is that accurate, folks?
15:46:02 <otaylor> +1 to meh
15:46:50 <kalev> I can get behind meh! +1 :)
15:46:54 <mclasen___> just trying to stick the blame to the kernel guys :-)
15:46:59 <stickster> Well look -- we have fairly reliable user-uptake statistics.  How bad would it be to drop these images for F24, check the effects on our trend (which is up over the course of F21-23, by the way), and consider whether to bring them back in F25, assuming there is no move to drop i686 as primary arch Fedora-wide?
15:47:21 <dgilmore> stickster: it is not really possible
15:47:50 <stickster> dgilmore: please illuminate us ;-)
15:47:51 <mcatanzaro> I would just drop it and be done with it, or not drop it.
15:47:53 <dgilmore> the tooling likely needs some major work to drop an arch  for somethings
15:48:10 <dgilmore> It would need investigation on what can be done
15:48:45 <jwb> stickster: the problem with drop then add is that once you drop it and people cannot get it, they will move to something else and very likely not come back.
15:48:56 <dgilmore> stickster: and if it comes after the compose is done, we have to manually remove bits and update bits
15:48:56 <stickster> dgilmore: This is the same as the F24 Change proposed for Server
15:49:00 <jwb> stickster: particularly with only one release between.  too much churn.
15:49:13 <dgilmore> we do not have any tooling to cleanly clean it up
15:49:25 <dgilmore> stickster: I have not seen thier proposal
15:49:55 <stickster> dgilmore: It was proposed back in August. I assume this has come up in FESCo, right?
15:50:05 <stickster> never mind, we can take this offline from this meeting
15:50:20 <dgilmore> stickster: it was agreed by fesco that i386 would not be release blocking
15:50:36 <dgilmore> stickster: but that is different to removing things after the fact
15:51:02 <jwb> i believe the Server proposal was to never create it to begin with.
15:51:33 <stickster> mclasen___: mcatanzaro: otaylor: kalev: So we'll take "meh" for now as "unless we get more info, and since the related F24 Server Change isn't clearly happening either, do nothing for now." Fair?
15:51:37 <mclasen___> if the kernel just ExcludeArch: i686, that should do it ?
15:52:07 <stickster> may not be ideal to me, but I respect I'm just one voice here :-)
15:52:14 <dgilmore> mclasen___: if it does that then we have to disable 32 bit entirely
15:52:42 <kalev> well, 32 bit multiarch is still useful for skype support, for example
15:52:42 <dgilmore> since that would remove kernel-headers so we will not be able to build any 32 bit x86 code
15:53:29 <jwb> well, if you just blindly did that without thinking, yes.
15:53:35 <jwb> but you know, thought is generally required
15:53:39 <stickster> kalev: Right, we weren't proposing dropping multiarch, just installation images like the DVD and netinst ISO.
15:54:09 <kalev> yeah, I was just replying to dgilmore's comment to disabling 32 bit entirely
15:54:12 <dgilmore> releng is working to enable a redefinition of secondary arch. which if we get what we want in f25 maybe f26 we could make i386 secondary but keep the multilib support primary
15:54:24 <stickster> But... I think the discussion shows there's really not enough support to do it (regardless of technical issues)
15:54:58 <kalev> perhaps we can downplay i686 images even more on the web site, if we end up building them
15:55:05 <stickster> #info Quorum in attendance was not really happy with idea to drop i686 images outright; there may be technical issues as well; lack of clear support means we will stick with status quo for now.
15:55:10 <kparal> if I may provide another data point, a few months back we tried Workstation i686 on some i686 hardware we managed to find in our office, and in 3 of 3 cases the system was either almost of completely unusable. that mostly came from old graphic cards that were sold in i686 era, which no longer properly work with modern desktop (including intel). I can't imagine how a sizeable portion of our users base uses gnome3 on i686 hardware
15:55:11 <kparal> regularly, except for VMs. but that's just my single experience.
15:55:19 <bowlofeggs> but what about my pentium III? ☺
15:55:23 <bowlofeggs> (j/k)
15:55:39 <stickster> Thanks for input kparal, I know it's anecdotal but it's still interesting.
15:55:49 <kalev> right, I think the expectation here is that keeping 32 bit images is _only_ for running on 64 bit capable machines to save RAM
15:56:22 <stickster> OK, let's move on guys
15:57:08 <stickster> #action stickster let sgallagh know about uncertain status of F24 Change for Server i686 droppage
15:57:20 <sgallagh> He is aware
15:57:27 <stickster> ah, hi sgallagh  o/
15:58:12 <stickster> #topic Changes for F24
15:58:38 <stickster> Sorry we only have a couple minutes for this. mclasen___ or kalev, do you know whether we have a general GNOME 3.20 update change in already?
15:59:01 * stickster thought we usually have that
15:59:32 <kalev> I don't think we have one yet
16:00:04 * mcatanzaro questions the need for proposing inevitable version updates as a formal change
16:00:31 <kalev> I could put together a barebones 3.20 change page without details if it helps
16:00:40 <stickster> kalev: It's probably in large part copypasta from 3.18
16:00:46 <stickster> So not a lot of work I think
16:00:54 * kalev nods.
16:00:54 <stickster> kalev: thank you
16:01:02 <kalev> will do!
16:01:05 <stickster> #action kalev create F24 Change page for GNOME 3.20
16:01:14 <stickster> Sorry for running out of time guys, but thank you for the great discussion.
16:01:34 <stickster> #action stickster revive Test Day discussion on list
16:01:41 <stickster> (note for myself here) :-)
16:01:46 <stickster> Thanks for coming everyone!
16:01:48 <stickster> #endmeeting