15:00:04 #startmeeting 15:00:04 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00:04 #meetingname workstation 15:00:04 The meeting name has been set to 'workstation' 15:00:04 #meetingtopic Workstation WG meeting 15:00:04 #topic init 15:00:11 #chair juhp cwickert otaylor mclasen cschalle ryanlerch jwb kalev 15:00:11 Current chairs: cschalle cwickert juhp jwb kalev mclasen otaylor ryanlerch 15:00:32 ok, i know cschalle and ryanlerch are going to miss today 15:00:36 who else is around? 15:00:48 * kalev appears in a cloud of magical dust. 15:00:54 I'm around 15:01:01 * sgallagh coughs at the dust 15:01:11 . 15:01:29 hi 15:01:44 anyone heard from mclasen? 15:02:02 * cwickert is sick an in bed... 15:02:20 cwickert, ok. i'll assume you're missing today then and hope you feel better 15:02:35 jwb: mclasen is definitely around this morning ... I'd give him a few minutes 15:02:40 sure, no rush 15:03:32 jwb: I will be lurking, but don't expect much from me 15:03:40 cwickert, fair enough 15:05:27 hm 15:06:15 doesn't look like enough wg members to make decisions 15:06:52 drago01, i was just thinking that 15:07:03 * mclasen apologizes for being late 15:07:35 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 #topic Include wayland session by default for F21? 15:07:59 ok, I think cschalle is out on a customer visit today, fyi 15:08:05 mclasen, you proposed this one. want to cover it? 15:08:16 sure 15:08:34 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 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 its a really tiny package that just installs a desktop file, essentially 15:09:32 how stable is it? :) 15:09:33 to make the Wayland session appear in the session chooser on the login screen 15:09:50 shouldn't we somehow warn that it is incomplete / just a preview? 15:10:09 X will be the default, of course 15:10:17 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 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 I think it is useful to get bug reports, yes 15:11:13 last I tried it didn't seem to work yet in kvm 15:11:27 I should file a bug... or look in bz 15:11:33 I'm also not too worried that _everybody_ is going to try it - the session chooser is somewhat hidden 15:11:41 true 15:11:52 should we add something about it being a technology preview to the release notes? 15:12:03 or should we leave that out entirely and let people find it on their own? 15:12:30 juhp: kernel bug 15:12:35 ah 15:12:55 juhp: the "dumb" kms drivers have broken page flip and simpledrm hasn't landed yet 15:12:55 drago01, in which area? 15:13:01 oh 15:13:14 drago01, any eta? :) 15:13:18 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 stuff to get to a something that we're actualyl advertising as a feature 15:13:39 juhp: not sure what the current state is ... can try to find out 15:13:55 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 (By shipping it - I mean, having everybody have the option without installing anything extra) 15:14:02 drago01, thanks 15:14:14 jwb: "dumb" here means qxl/cirrus 15:14:25 drago01, yep 15:14:47 drago01: do you know what happens on nouveau/radeon? 15:15:14 otaylor: I think we want to work on fixing and stabilizing in 3.14, yes 15:15:20 otaylor: they should work fine 15:15:40 otaylor: elad has tested on radeon iirc 15:16:25 proposal: include the wayland session for beta and reevaluate the decision before the final freeze 15:16:33 kalev, +1 15:16:38 +1 15:16:42 +1 15:17:06 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 +1 15:17:35 +1 15:18:01 #agreed include the wayland session for beta and reevaluate the decision before the final freeze 15:18:04 great 15:18:11 ok, let's move on 15:18:19 #topic Open WG seat 15:18:35 so last meeting we agreed to discuss suggestions for the open seat on the list 15:18:44 rdieter and aday were the only suggestions made 15:19:09 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 but we got a couple of affirmations for rdieter and i think rdieter is around 15:20:10 rdieter, can i put you on the spot? 15:20:16 * rdieter waves, sure 15:20:41 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 jwb: aday is away, indeed 15:24:21 in other news, I pushed the comps change to add the wayland session 15:24:33 :) 15:24:54 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 thanks rdieter 15:25:41 anyone have any comments or questions? 15:25:46 or other candidate suggestions? 15:26:41 rdieter: just curious, are you planning on deploying the classic session or the regular gnome session by default? 15:27:23 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 otaylor, +1 15:27:39 kalev: good question. Initial plan is regular gnome session ( as well as kde/plasma too) 15:29:28 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 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 (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 otaylor, indeed 15:30:53 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 one thing that I think is lacking in Workstation right now is Qt app appdata coverage 15:31:32 rdieter: excellent, we need any testers in that area that we can get 15:31:45 some high profile apps like Qt Creator aren't even showing up in the software installer 15:32:22 kalev: good point, that too can be on my radar to help work on 15:32:28 awesome :) 15:32:44 (well, it would be regardless) 15:33:02 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 shall we move on to the next topic? 15:34:01 * jwb assumes so 15:34:14 #topic Upgrades 15:34:23 lots of discussions on this topic on the list 15:34:41 i think we left off there with a vague idea about switching defaults 15:35:02 where apps are harder (user configuration/data) but core components shouldn't really matter 15:35:07 is that a fair assessment otaylor ? 15:35:54 I would like for us to define a core set of packages that are unremovable without removing the workstation branding 15:36:19 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 but that should not cover (all) apps, because I think users should be free to remove those post-install 15:36:30 kalev, that sounds like a good idea, but it's not specific to upgrades, right? 15:37:00 and when upgrading fedora-release-workstation, it would automatically pull in all the new core packages in a newer release 15:37:12 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 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 I don't know how to get there without causing a massive outrage that upgrades remove apps :( 15:40:08 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 maybe if the upgrader asks for confirmation before removing apps, but that can quickly get compilcated too 15:40:59 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 kalev, yeah, that was my suggestion 15:41:24 I'll note that we should probably implement a graphical distro version upgrader 15:41:39 and I'm not convinced that it should be based on fedup, given it's current architecture 15:42:12 my high level idea would be that once a given fedora release is about to become unsupported (1 month before?) 15:42:14 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 it would start nagging the user to upgrade 15:43:01 and then when the users says yes, download everything in the background and prepare and offline update 15:43:18 and then ask for confirmation to reboot, basically reusing the current PK offline updates mechanism 15:43:22 and not using fedup at all 15:43:34 kalev: had this discussion once 15:43:47 kalev: the thing is we need fedup to deal with stuff like usrmove 15:43:48 kalev: isn't that more or less what fedup does, though ? 15:44:08 mclasen: yes, except that it's basically unmaintained right now, still using yum and so on 15:44:32 kalev: the regular offline updates does not have the infrastructure for that 15:44:52 right, but perhaps it's not needed 15:44:56 wwoods, fedup is basically unmaintained? 15:45:22 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 right 15:45:36 in particular since the fedup we're using to go to f21 actually runs on f20 15:45:47 yeah 15:46:10 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 actually it only uses yum for depsolve and download 15:46:18 it does the update using rpm directly 15:46:47 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 I don't think we should be rushing to replace fedup - having competing upgrade mechanisms doesn't sound like a win 15:47:37 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 mclasen, yep, was just going to say the same 15:47:59 kalev, I agree a gui might be helpful though 15:48:26 yes, I was rushing ahead, I was thinking more like writing an updater during the F22 cycle 15:49:09 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 jwb: ...what makes you say that? 15:49:37 otaylor: yep 15:49:54 wwoods, kalev said it 15:49:58 pk offline updates mechanism is insufficient for major version upgrades 15:49:59 otaylor: of those, Baobab might have been dropped accidetantally 15:50:23 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 fedup is really just the reference implementation of a way to do upgrades that kalev is describing 15:52:03 (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 if you want to support upgrades, you want your packaging / initramfs tools to handle that *process* 15:52:22 (I guess its' just opening a local file in the browser) 15:52:29 fedup itself is just an implementation. I'm getting as much of the fedup infrastructure as I can into upstream projects 15:53:24 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 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 kalev: because you can't upgrade the system while the system is running 15:54:18 aha 15:54:20 if you could, you wouldn't need PK offline updates... 15:54:44 various subtle and exceedingly hard-to-trace things can happen when you update libraries out from under running programs 15:55:04 ok, but we're digressing again 15:55:06 well, it's just one program running, the offline updater 15:55:08 or restart daemons in unpredictable order with slightly different versions 15:55:36 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 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 also you're running with the old SELinux policy 15:56:09 ah yes, that one is a really good point 15:56:19 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 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 => F at this point or not 15:56:57 otaylor, i'd like to, but with 4 minutes remaining we might want to push it back to the list 15:57:31 wwoods: I think the fedup architecture is pretty much right 15:57:46 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 jwb: Yeah, better to wait 15:58:12 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 kalev, i don't think the packaging guidelines cover transition points very well 15:58:45 they don't, and they should 15:58:47 certainly not N-1/N-2 distinction 15:59:14 wwoods, theoretically, that would be in the updates guidelines that don't exist 15:59:23 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 officially leap-upgrades aren't supported, AFAIK 15:59:44 for no real technical reason 15:59:51 that is also my impression 16:00:08 wwoods, i believe it's more a "we don't have the resources to adequately test that" 16:00:14 I guess not many test it (before release anyway) 16:00:16 kalev: good question. It *should*. :) I'll double-check 16:00:28 ok, we're out of time 16:00:35 any last items before we adjourn? 16:00:36 (that's how long *I* support Obsoletes at least) 16:00:50 me too :) 16:01:22 rdieter, kalev : why? does that two lines in the spec hurt that much? 16:01:34 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 though EDT is also ending soon I guess.... 16:02:36 when exactly _is_ edt ending ? 16:02:52 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 26/10 16:04:07 mclasen, Nov 2 it looks like 16:04:08 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 otaylor, yeah, good point 16:04:25 okay 16:04:59 I hope at least we will adjust the time for EST :) 16:05:14 or Winter time 16:05:21 yeah, i'll make sure to bring it up on the list 16:05:28 jwb, thanks 16:05:29 ok, going to end the meeting 16:05:31 thanks everyone 16:05:33 #endmeeting