15:00:04 <jwb> #startmeeting
15:00:04 <zodbot> Meeting started Wed Oct  8 15:00:04 2014 UTC.  The chair is jwb. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:04 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:04 <jwb> #meetingname workstation
15:00:04 <zodbot> The meeting name has been set to 'workstation'
15:00:04 <jwb> #meetingtopic Workstation WG meeting
15:00:04 <jwb> #topic init
15:00:11 <jwb> #chair juhp cwickert otaylor mclasen cschalle ryanlerch jwb kalev
15:00:11 <zodbot> Current chairs: cschalle cwickert juhp jwb kalev mclasen otaylor ryanlerch
15:00:32 <jwb> ok, i know cschalle and ryanlerch are going to miss today
15:00:36 <jwb> who else is around?
15:00:48 * kalev appears in a cloud of magical dust.
15:00:54 <otaylor> I'm around
15:01:01 * sgallagh coughs at the dust
15:01:11 <drago01> .
15:01:29 <juhp_> hi
15:01:44 <jwb> anyone heard from mclasen?
15:02:02 * cwickert is sick an in bed...
15:02:20 <jwb> cwickert, ok.  i'll assume you're missing today then and hope you feel better
15:02:35 <otaylor> jwb: mclasen is definitely around this morning ... I'd give him a few minutes
15:02:40 <jwb> sure, no rush
15:03:32 <cwickert> jwb: I will be lurking, but don't expect much from me
15:03:40 <jwb> cwickert, fair enough
15:05:27 <jwb> hm
15:06:15 <drago01> doesn't look like enough wg members to make decisions
15:06:52 <jwb> drago01, i was just thinking that
15:07:03 * mclasen apologizes for being late
15:07:35 <jwb> hi mclasen.  we have 5 now.  i think we'll aim for a decision on the first item, and just discussion on the next two
15:07:49 <jwb> #topic Include wayland session by default for F21?
15:07:59 <mclasen> ok, I think cschalle is out on a customer visit today, fyi
15:08:05 <jwb> mclasen, you proposed this one.  want to cover it?
15:08:16 <mclasen> sure
15:08:34 <mclasen> it was pointed out a while ago (on the test list, I think ? ) that we don't have the wayland session installed by default
15:09:04 <mclasen> since getting the wayland port working was a major part of what we've done this cycle, it does make sense to me to include it
15:09:23 <mclasen> its a really tiny package that just installs a desktop file, essentially
15:09:32 <juhp_> how stable is it? :)
15:09:33 <mclasen> to make the Wayland session appear in the session chooser on the login screen
15:09:50 <drago01> shouldn't we somehow warn that it is incomplete / just a preview?
15:10:09 <mclasen> X will be the default, of course
15:10:17 <kalev> I think the main question here is if mutter / gnome-shell are ready for an inflow of wayland bug reports that being included by default would bring
15:10:21 <kalev> if it's useful to them, then let's include it: get more testing coverage as we're planning on making it the default in a future release anyway
15:10:51 <mclasen> I think it is useful to get bug reports, yes
15:11:13 <juhp_> last I tried it didn't seem to work yet in kvm
15:11:27 <juhp_> I should file a bug... or look in bz
15:11:33 <mclasen> I'm also not too worried that _everybody_ is going to try it - the session chooser is somewhat hidden
15:11:41 <juhp_> true
15:11:52 <jwb> should we add something about it being a technology preview to the release notes?
15:12:03 <jwb> or should we leave that out entirely and let people find it on their own?
15:12:30 <drago01> juhp: kernel bug
15:12:35 <juhp_> ah
15:12:55 <drago01> juhp: the "dumb" kms drivers have broken page flip and simpledrm hasn't landed yet
15:12:55 <jwb> drago01, in which area?
15:13:01 <jwb> oh
15:13:14 <juhp_> drago01, any eta? :)
15:13:18 <otaylor> I think it depends a bit on how much effort we want to work on fixing and stabilizing wayland in 3.14.x - if at this point, we just are forgetting about it and moving on to 3.16, then I'd be hesitant about shipping it .... but if we are trying to have the best possible Wayland on Fedora release day (even if that means work that doesnt' help for 3.16) , then i think there's a lot to be said for not making people install
15:13:18 <otaylor> stuff to get to a something that we're actualyl advertising as a feature
15:13:39 <drago01> juhp: not sure what the current state is ... can try to find out
15:13:55 <kalev> also, a possible middle ground would be to include it for beta to get some testing, and take it out for final
15:13:59 <otaylor> (By shipping it - I mean, having everybody have the option without installing anything extra)
15:14:02 <juhp_> drago01, thanks
15:14:14 <drago01> jwb: "dumb" here means qxl/cirrus
15:14:25 <jwb> drago01, yep
15:14:47 <otaylor> drago01: do you know what happens on nouveau/radeon?
15:15:14 <mclasen> otaylor: I think we want to work on fixing and stabilizing in 3.14, yes
15:15:20 <drago01> otaylor: they should work fine
15:15:40 <drago01> otaylor: elad has tested on radeon iirc
15:16:25 <kalev> proposal: include the wayland session for beta and reevaluate the decision before the final freeze
15:16:33 <jwb> kalev, +1
15:16:38 <juhp_> +1
15:16:42 <kalev> +1
15:17:06 <otaylor> As compared to previous releases, it helps that we're not planning any massive rewrites of how wayland stuff works for the next cycle
15:17:26 <mclasen> +1
15:17:35 <otaylor> +1
15:18:01 <jwb> #agreed include the wayland session for beta and reevaluate the decision before the final freeze
15:18:04 <jwb> great
15:18:11 <jwb> ok, let's move on
15:18:19 <jwb> #topic Open WG seat
15:18:35 <jwb> so last meeting we agreed to discuss suggestions for the open seat on the list
15:18:44 <jwb> rdieter and aday were the only suggestions made
15:19:09 <jwb> i don't want to decide this today because i believe allan is on PTO and hasn't had a chance to even confirm he's interested (though i would assume so)
15:19:32 <jwb> but we got a couple of affirmations for rdieter and i think rdieter is around
15:20:10 <jwb> rdieter, can i put you on the spot?
15:20:16 * rdieter waves, sure
15:20:41 <jwb> rdieter, thanks for being a good sport.  maybe just give a few words on why you're interested in the WG seat and what you'd like to work towards?
15:23:07 <mclasen> jwb: aday is away, indeed
15:24:21 <kalev> in other news, I pushed the comps change to add the wayland session
15:24:33 <juhp_> :)
15:24:54 <rdieter> great.  I guess my primary motivation is wanting to help with distro-wide/workstation integration (using shared/common technologies and infrastructure), ensuring quality qt/kde integration.  In particular, I plan on deploying workstation at @dayjob , so have vested interest in helping make it great.
15:25:29 * cwickert would love to see rdieter in the WG
15:25:32 <jwb> thanks rdieter
15:25:41 <jwb> anyone have any comments or questions?
15:25:46 <jwb> or other candidate suggestions?
15:26:41 <kalev> rdieter: just curious, are you planning on deploying the classic session or the regular gnome session by default?
15:27:23 <otaylor> I definitely would like to see a non-RH person in that seat - and I think rdieter would be a good candidate and give us diversity on the WG
15:27:38 <juhp_> otaylor, +1
15:27:39 <rdieter> kalev: good question.  Initial plan is regular gnome session ( as well as kde/plasma too)
15:29:28 <jwb> anything else on this topic?  as i said, i don't want to decide without at least talking to aday first.  seems only fair :)
15:29:47 <rdieter> fair warning, we use NFS $HOME, so that's something I'll be testing a lot, and working toward getting to 'just work' as close as possible
15:30:08 <otaylor> (I would like to emphasize that we have some excellent and active non-RH contributors who are more GNOME-connected as well - and I'm really happy about that)
15:30:21 <jwb> otaylor, indeed
15:30:53 <jwb> rdieter, heh, i think that's an area we aren't covering extensively at the moment, so sounds like your attention will be helpful :)
15:31:28 <kalev> one thing that I think is lacking in Workstation right now is Qt app appdata coverage
15:31:32 <mclasen> rdieter: excellent, we need any testers in that area that we can get
15:31:45 <kalev> some high profile apps like Qt Creator aren't even showing up in the software installer
15:32:22 <rdieter> kalev: good point, that too can be on my radar to help work on
15:32:28 <kalev> awesome :)
15:32:44 <rdieter> (well, it would be regardless)
15:33:02 <mclasen> kalev: we could probably make progress on that by just making a small list of 'missing high-profile apps' and hand out badges for contributions
15:33:23 <jwb> shall we move on to the next topic?
15:34:01 * jwb assumes so
15:34:14 <jwb> #topic Upgrades
15:34:23 <jwb> lots of discussions on this topic on the list
15:34:41 <jwb> i think we left off there with a vague idea about switching defaults
15:35:02 <jwb> where apps are harder (user configuration/data) but core components shouldn't really matter
15:35:07 <jwb> is that a fair assessment otaylor ?
15:35:54 <kalev> I would like for us to define a core set of packages that are unremovable without removing the workstation branding
15:36:19 <otaylor> OK, the basic idea is that I want peopel upgrading to see what the new version looks like without any breakage that has to be manually fixed up by removing leftovers
15:36:24 <kalev> but that should not cover (all) apps, because I think users should be free to remove those post-install
15:36:30 <jwb> kalev, that sounds like a good idea, but it's not specific to upgrades, right?
15:37:00 <kalev> and when upgrading fedora-release-workstation, it would automatically pull in all the new core packages in a newer release
15:37:12 <otaylor> In some cases, removing leftovers can be done with an Obsoletes: if it's crystal clear that the old thing is dead as a doornail
15:38:44 <otaylor> But my proposal - and it was intentionally somewhat vague - is that we should and make the goal the experience of not having duplicates
15:40:03 <kalev> I don't know how to get there without causing a massive outrage that upgrades remove apps :(
15:40:08 <otaylor> Duplicates show up in the app overview, they show up in the search results, they can provide a confusing "Open with", etc. - there is active harm
15:40:54 <kalev> maybe if the upgrader asks for confirmation before removing apps, but that can quickly get compilcated too
15:40:59 <otaylor> kalev: It's defintiely a concern - and it's much more of a concern when you actually use Obsoletes: - because then the user can't isntall the app back
15:41:03 <jwb> kalev, yeah, that was my suggestion
15:41:24 <kalev> I'll note that we should probably implement a graphical distro version upgrader
15:41:39 <kalev> and I'm not convinced that it should be based on fedup, given it's current architecture
15:42:12 <kalev> my high level idea would be that once a given fedora release is about to become unsupported (1 month before?)
15:42:14 <otaylor> It's probably easier to do this with actual examples then in theory  - though by the time we get to actual examples for F22 we may be to the point where it's too late to add any necessary infrastructure
15:42:30 <kalev> it would start nagging the user to upgrade
15:43:01 <kalev> and then when the users says yes, download everything in the background and prepare and offline update
15:43:18 <kalev> and then ask for confirmation to reboot, basically reusing the current PK offline updates mechanism
15:43:22 <kalev> and not using fedup at all
15:43:34 <drago01> kalev: had this discussion once
15:43:47 <drago01> kalev: the thing is we need fedup to deal with stuff like usrmove
15:43:48 <mclasen> kalev: isn't that more or less what fedup does, though ?
15:44:08 <kalev> mclasen: yes, except that it's basically unmaintained right now, still using yum and so on
15:44:32 <drago01> kalev: the regular offline updates does not have the infrastructure for that
15:44:52 <kalev> right, but perhaps it's not needed
15:44:56 <jwb> wwoods, fedup is basically unmaintained?
15:45:22 <mclasen> kalev: given that we're not switching to dnf by default yet, it wouldn't seem too alarming that fedup is using it
15:45:33 <juhp_> right
15:45:36 <mclasen> in particular since the fedup we're using to go to f21 actually runs on f20
15:45:47 <jwb> yeah
15:46:10 <kalev> if we wanted to base it on fedup, we'd need to turn it into a library and expose a dbus interface
15:46:10 <drago01> actually it only uses yum for depsolve and download
15:46:18 <drago01> it does the update using rpm directly
15:46:47 <kalev> sorry, not a library, but a daemon -- which would then handle the updater running in root and let us run the gui as a user process
15:47:36 <otaylor> I don't think we should be rushing to replace fedup - having competing upgrade mechanisms doesn't sound like a win
15:47:37 <mclasen> maybe discussing the ui is a bit premature, since we don't seem to have a full agreement yet on what we want the tool to actually do
15:47:51 <jwb> mclasen, yep, was just going to say the same
15:47:59 <juhp_> kalev, I agree a gui might be helpful though
15:48:26 <kalev> yes, I was rushing ahead, I was thinking more like writing an updater during the F22 cycle
15:49:09 <otaylor> kalev: so, if I look at your mail from this morning, it looks like the left-over apps for F21 will be Baobob, firewall-config, and fedora-release-notes?
15:49:12 <wwoods> jwb: ...what makes you say that?
15:49:37 <kalev> otaylor: yep
15:49:54 <jwb> wwoods, kalev said it
15:49:58 <wwoods> pk offline updates mechanism is insufficient for major version upgrades
15:49:59 <kalev> otaylor: of those, Baobab might have been dropped accidetantally
15:50:23 <otaylor> Do we know if fedora-release-notes launcher will do the right thing for the F22 release notes? (Is the package still maintained?)
15:51:44 <wwoods> fedup is really just the reference implementation of a way to do upgrades that kalev is describing
15:52:03 <otaylor> (Right now it goes to F21 release notes, but since there are no F22 release notes yet, that doesn't really tell me anything)
15:52:06 <wwoods> if you want to support upgrades, you want your packaging / initramfs tools to handle that *process*
15:52:22 <otaylor> (I guess its' just opening a local file in the browser)
15:52:29 <wwoods> fedup itself is just an implementation. I'm getting as much of the fedup infrastructure as I can into upstream projects
15:53:24 <kalev> wwoods: why does the offline updater need to run from initramfs? (I'm just trying to understand the reasons, it's not a trick question)
15:53:29 <wwoods> so (for example) to support system upgrades, dnf should probably have a way of doing the "modify $releasever and download all packages that would be updates" thing
15:53:45 <wwoods> kalev: because you can't upgrade the system while the system is running
15:54:18 <kalev> aha
15:54:20 <jwb> if you could, you wouldn't need PK offline updates...
15:54:44 <wwoods> various subtle and exceedingly hard-to-trace things can happen when you update libraries out from under running programs
15:55:04 <jwb> ok, but we're digressing again
15:55:06 <kalev> well, it's just one program running, the offline updater
15:55:08 <wwoods> or restart daemons in unpredictable order with slightly different versions
15:55:36 <wwoods> kalev: no, it isn't. go actually look at the implementation; udev, systemd, all your storage daemons, plymouth, etc. are all running
15:55:50 <jwb> i think at this point i'm happy to let you guys talk, but we aren't actually making progress on what we want from the upgrade process itself
15:55:55 <wwoods> also you're running with the old SELinux policy
15:56:09 <kalev> ah yes, that one is a really good point
15:56:19 <wwoods> if it was *possible* to do it the other way, don't you think I would have done it the other way
15:56:26 <otaylor> jwb: Yeah - as far as I'm concerned, there are no active decisions that have to be made on my upgrades proposal at this point - I don't know if we want to discuss F<m> => F<n> at this point or not
15:56:57 <jwb> otaylor, i'd like to, but with 4 minutes remaining we might want to push it back to the list
15:57:31 <mclasen> wwoods: I think the fedup architecture is pretty much right
15:57:46 <wwoods> the point is this: if you're going to discuss upgrades, you should assume that the fedup *process* is basically the best way to do things, and make sure your tools / repos / etc. work with that process
15:57:53 <otaylor> jwb: Yeah, better to wait
15:58:12 <kalev> rdieter: do you know if the fedora packaging guidelines require that package updates (obsoletes, in particular) should work across 2 fedora releases, e.g. F19 -> F21?
15:58:38 <jwb> kalev, i don't think the packaging guidelines cover transition points very well
15:58:45 <wwoods> they don't, and they should
15:58:47 <jwb> certainly not N-1/N-2 distinction
15:59:14 <jwb> wwoods, theoretically, that would be in the updates guidelines that don't exist
15:59:23 <kalev> I remember some text about this somewhere, but the packaging guidelines have become so massive that it's really hard to find now when I need it
15:59:26 <wwoods> officially leap-upgrades aren't supported, AFAIK
15:59:44 <wwoods> for no real technical reason
15:59:51 <juhp_> that is also my impression
16:00:08 <jwb> wwoods, i believe it's more a "we don't have the resources to adequately test that"
16:00:14 <juhp_> I guess not many test it (before release anyway)
16:00:16 <rdieter> kalev: good question.  It *should*. :)  I'll double-check
16:00:28 <jwb> ok, we're out of time
16:00:35 <jwb> any last items before we adjourn?
16:00:36 <rdieter> (that's how long *I* support Obsoletes at least)
16:00:50 <kalev> me too :)
16:01:22 <drago01> rdieter, kalev : why? does that two lines in the spec hurt that much?
16:01:34 <juhp_> jwb, I wanted to ask if there is any chance of starting the meeting 1 hour earlier? - but I don't know if that is difficult for the current active members
16:02:10 <juhp_> though EDT is also ending soon I guess....
16:02:36 <mclasen> when exactly _is_ edt ending ?
16:02:52 <kalev> drago01: no, I meant it the other way around -- leave the obsoletes and stuff in for  _at least_ two versions to support upgrades across two major fedora releases
16:02:56 * mclasen can't get his kids out of bed now that its dark in the morning...
16:03:38 <drago01> 26/10
16:04:07 <juhp_> mclasen, Nov 2 it looks like
16:04:08 <otaylor> dayight savings ends Nov 2 in the US it's probably best to wait until we have the vacant seat filled until we refigure the times
16:04:22 <jwb> otaylor, yeah, good point
16:04:25 <juhp_> okay
16:04:59 <juhp_> I hope at least we will adjust the time for EST :)
16:05:14 <juhp_> or Winter time
16:05:21 <jwb> yeah, i'll make sure to bring it up on the list
16:05:28 <juhp_> jwb, thanks
16:05:29 <jwb> ok, going to end the meeting
16:05:31 <jwb> thanks everyone
16:05:33 <jwb> #endmeeting