13:01:21 #startmeeting Workstation WG 13:01:21 Meeting started Mon Jun 5 13:01:21 2017 UTC. The chair is stickster. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:01:21 Useful Commands: #action #agreed #halp #info #idea #link #topic. 13:01:21 The meeting name has been set to 'workstation_wg' 13:01:25 #meetingname workstation 13:01:25 The meeting name has been set to 'workstation' 13:01:28 * mcatanzaro yawns 13:01:29 #topic Roll call 13:01:32 .hello pfrields 13:01:32 .hello catanzaro 13:01:33 stickster: pfrields 'Paul W. Frields' 13:01:36 mcatanzaro: catanzaro 'Michael Catanzaro' 13:01:39 .hello otaylor 13:01:45 otaylor: otaylor 'Owen Taylor' 13:01:54 (FYI I'll be leaving early today) 13:02:26 .hello ryanlerch 13:02:28 ryanlerch: ryanlerch 'Ryan Lerch' 13:03:09 mcatanzaro: no worries 13:03:10 .hello kalev 13:03:11 kalev_: kalev 'Kalev Lember' 13:03:20 #chair mcatanzaro otaylor ryanlerch kalev_ 13:03:20 Current chairs: kalev_ mcatanzaro otaylor ryanlerch stickster 13:04:35 * stickster rummages for agenda from the issues list 13:05:09 #topic Nautilus add-on by default 13:05:10 #link https://pagure.io/fedora-workstation/issue/10 13:05:32 kalev_: did you get a chance to make this change, adding gnome-terminal-nautilus to default? 13:05:45 er, default Workstation packages 13:06:20 #chair mclasen 13:06:20 Current chairs: kalev_ mcatanzaro mclasen otaylor ryanlerch stickster 13:06:20 err, no, but let me go do this now 13:06:33 kalev_: Thanks -- and when done, you can comment and close that issue as fixed 13:06:48 * stickster notes this may not change anything until post-Beta 13:06:53 yep, will do 13:07:45 #action kalev_ is adding gnome-terminal-nautilus ASAP, should be in composes soon (no later than right after Beta, possibly for Beta) 13:09:07 #topic Packaging guidelines for app independence 13:09:09 #link https://pagure.io/fedora-workstation/issue/13 13:09:16 mcatanzaro: Care to give update here? 13:09:54 Since we decided that GNOME Software should report to the user when apps depend on each other, I toned down the wording of the policy significantly to reflect feedback from rdieter. 13:10:28 Basically now it is toothless as everything is just a "should," but it is still worthwhile as it represents some formal guidelines we can point people too when we have problems. E.g. when blivet-gui turns up in the default install. 13:10:39 So at this point I'm looking for approval to present this to the packaging committee. 13:10:47 #link https://fedoraproject.org/wiki/PackagingDrafts/IndependentApplications 13:11:32 mcatanzaro: Hmm, to me, that sound slike a lot of technical work to work around a packaging bug 13:12:17 mcatanzaro: Sorry if my memory is hazy -- is there an app whose behavior prompted this? 13:12:21 fwiw, I approve of the amended draft 13:12:39 stickster: We've had several cases in the past, most recently anaconda depending on blivet-gui. 13:12:46 Ah right 13:13:00 I do recall now, thanks 13:14:25 otaylor: My original draft considered this situation a packaging bug and had a bunch of MUST NOTs, but then we decided to modify gnome-software so it doesn't seem essential to avoid application interdependencies anymore. They can be useful in some circumstances (e.g. mclasen's example: game level editor). But in most cases, yeah it's just a bug, so 13:14:25 talking about it in the packaging guidelines seems worthwhile. 13:14:27 * otaylor wonders if we can have a packaging guideline not to call your application "Blivet GUI" ;-) 13:14:58 Like "what's a blivet, and why do I need a GUI to control it?". 13:15:09 and why is it on my system ?! 13:15:24 mcatanzaro: the thing is, that the cases that make sense, make sense 13:15:30 As one of my team members is fond of saying, there are two difficult problems in software engineering: cache invalidation and naming things. 13:16:21 mcatanzaro: but yes, I think the "should not generally" is fine - it's just that the exceptions need to be made for the sake of the user rather than the sake of technical impossibility 13:17:33 otaylor: That's pretty much what I was trying to get at with my current wording. 13:18:23 I think the draft looks good as it is now, no objections from me 13:18:31 mcatanzaro: Looks good to me too 13:19:06 I made two trivial tweaks just now (just spelling-ish corrections), but this looks good to me as well. 13:20:16 should the instances of "application" be expanded out to GUI application in the application independence section? 13:20:45 hmm, good point ryanlerch 13:21:08 * kalev_ agrees 13:21:09 Could be, I figured it was assumed, but it's not in the existing text "If a package contains a GUI application" 13:21:24 I took it to follow as well, mcatanzaro, but you know how people love to language lawyer stuff... 13:21:40 OK, I'll add that and then take it to the packaging committee, agreed? 13:21:51 mcatanzaro: So did I understand correctly that GNOME Software *is* getting some changes to expose to the user that some other app might be installed, in the case of a {soft,} dependency? 13:21:59 +1 from me 13:22:29 stickster: That was mclasen's plan, yes. 13:22:32 stickster: yes 13:22:35 gotcha, thanks 13:22:40 This policy only makes sense if those changes land in gnome-software. 13:22:47 * stickster summarizes for minutes 13:23:07 (Well it makes sense regardless, but it should be way stricter without those changes.) 13:23:13 plan ? 13:23:20 #info mcatanzaro presented slightly altered packaging guideline change proposal, based on the fact that GNOME Software will soon gain ability to show when an app dependency will be installed 13:23:23 I didn't make a plan, I just voiced an opinion 13:23:37 #undo 13:23:37 Removing item from minutes: INFO by stickster at 13:23:20 : mcatanzaro presented slightly altered packaging guideline change proposal, based on the fact that GNOME Software will soon gain ability to show when an app dependency will be installed 13:23:40 that doesn't magically make code appear in gnome-software 13:24:25 * stickster backs out minutes while we get to the bottom of what is actually happening here. ;-) Obviously we want the guideline to agree with reality 13:25:08 I put it on my todo list now to make the gnome-software change 13:25:08 I'm sure it is somewhere on hughsie's todo list, but I don't expect it to be near the top 13:25:09 So if it's mclasen's opinion that gnome-software should do this, and kalev's opinion that gnome-software should do this... that sounds like a plan? ;) 13:25:15 did anyone talk with hughsie about adding the capability in Software to show when a dependency is installed? 13:25:30 mcatanzaro: mclasen: ^ That seems like the most important issue, not who agrees :-) 13:25:56 kalev_? 13:26:11 sorry kalev_, didn't mean to leave you out :-) 13:27:02 * stickster waits for a clarification... 13:28:09 let me ask this in a different way... Who is going to be accountable to talk with hughsie about this feature? ;-) 13:28:37 I can be 13:28:41 I'll do it 13:29:49 OK, I'll wait for an ACK from one of you that hughsie is OK with this before taking this policy to the packaging committee. So please let me know once you've chatted with him. 13:29:54 * stickster thinks all this makes sense, just want to get the ducks ordered correctly in their row ;-) ... I'll tag mclasen with this since kalev_ took the last one 13:30:05 * mcatanzaro needs to go now, ciao 13:30:17 #info mcatanzaro presented slightly altered packaging guideline change proposal, based on the concept of GNOME Software gaining ability to show when an app dependency will be installed 13:30:31 #info Needs sorting out with Software upstream first, though 13:30:57 #agreed WG members agree with text of proposal, contingent on Software changes 13:31:12 #action mclasen to chat w/ hughsie about changes in Software 13:31:52 #action mcatanzaro move forward with guidelines based on outcome of Software change plan 13:31:58 *whew* OK. 13:32:21 #topic Repo fixes for default install 13:32:25 #link https://pagure.io/fedora-workstation/issue/17 13:33:24 Here's what I recall about this. cschaller contacted mboddu about changes for repos, based on sgallagh recommendation. 13:33:52 But given the fact that we got no word back, and that locking everything up in one package goes against the spirit of the editions deciding the fate of third party repos, mattdm advised the following: 13:34:09 * Third party repo policy needs to be finished, and... 13:34:41 * ...contingent on that, it might be reasonable to ask for exception to keep carrying fedora-workstation-repositories 13:35:03 but since I know cschalle hasn't had time to work on this, it's been stuck at the moment, expect more to happen this week 13:35:10 stickster: sorry, I was busy in the Beta mumbo-jumbo. I think I can take a look at it sometime this week 13:35:27 mboddu: I figured -- that's been very draining, I'm sure. Thank you for working on Beta! 13:35:44 stickster: :) 13:35:50 mboddu: If you are able to get this change in, we're happy to discuss further here or in #fedora-workstation. 13:36:21 On the above: specifically, if third-party repos are to be "owned" by the Edition WGs, it makes sense for the corresponding packages to also be so owned 13:36:44 stickster: sure, I will read more about it and I will come back to you 13:37:16 mattdm: Agree or disagree: The third party repository policy must be completed and approved by {Council? FESCo? both?} before such a package is used. 13:37:47 * stickster just trying to clarify course of action here for the record, since this has been confusing and we don't want to ask rel-eng for multiple, clashy things. 13:38:18 stickster: agree. 13:38:36 mattdm: and IIRC this is a Council approval, right? 13:39:05 The Council approved the direction the policy is going in, but we have not approved a final version 13:39:13 *nod 13:39:22 #nick cschalle 13:39:59 * mattdm is on the train to th enew Boston office; cell signal is really spotty at this point in the tunnel :) 13:40:11 mattdm: no worries, I'm done summoning you :-D 13:40:12 The approval should not be a hard process at this point 13:40:34 just, the work of clearling up remaining questions and working out details needs to be done 13:41:03 #info mattdm confirms, need to finish third party repo policy, present to Council for final approval, then the WG should be able to control its own third party repo package without needing to call on rel-eng for changes each time 13:41:23 #action cschalle finish third party repo policy (with contribution from WG as needed) and present to Council 13:41:38 OK, a lot of monologue from me there, sorry all 13:42:18 kalev_: ryanlerch: mclasen: rdieter: otaylor: if you guys don't mind, I'd like to bring up an "other business" item 13:42:36 sure :) 13:42:42 #topic Other biz: Setting meeting agenda 13:42:43 kalev_: sure 13:42:52 err, stickster: sure 13:43:28 So just a reminder -- we now have https://pagure.io/fedora-workstation/issues rotating fairly regularly. I'm going to set meeting agenda based on one thing and one thing only: "meeting" tag set on an issue in that list, in order from earliest to latest unresolved issues. 13:43:37 * ryanlerch has one item with the backgrounds packages 13:44:04 ryanlerch: sure, I'll be done in like 1 more minute 13:44:14 stickster: sorry, ack 13:44:43 #info If you want something on the agenda, tag the issue with 'meeting' before the meeting happens. (Also open to last minute changes, we're not automatons after all.) 13:44:54 Any problem with that? 13:45:15 sounds like a good plan 13:45:21 +1 from me 13:45:30 This saves me from flailing about on a mailing list trying to determine what we need to talk about here :-) 13:46:05 #action stickster to set meeting reminder to also include issues URL for everyone's reference in advance 13:46:17 #topic Background wallpapers 13:46:20 Go ahead ryanlerch 13:46:25 thanks stickster 13:46:43 i have the backgrounds package all ready to go: 13:46:45 https://bodhi.fedoraproject.org/updates/FEDORA-2017-f8e0ef2850 13:47:06 just a little uninformed on how to proceed at this point in the release cycle. 13:47:10 stickster: +1 13:48:06 ryanlerch: mboddu might be able to correct me -- I think he knows enough about how this works now -- but I believe if that package is in stable, then we just make changes to comps at this point in order to fix the compose correctly 13:48:15 there is also the changes to the existing gnome-backgrounds package (splitting into sub-package), just not sure how to proceed at this point 13:48:49 ryanlerch: Ah, that would be another change needed then -- should be a fairly simple packaging fix, but I don't know who has access to that one 13:48:56 .whoowns gnome-backgrounds 13:48:56 stickster: kalev 13:49:01 Ah, that's pretty easy then :-D 13:49:13 stickster: the changes are done. 13:49:20 ryanlerch: I think wait for the F26 Beta to get released so that packages can be pushed to stable again, then push this stable and make the change to gnome-backgrounds 13:49:31 right, we're still in freeze 13:49:40 and put this through bodhi as well then 13:49:48 kalev_: okay! 13:49:59 the gnome-backgrounds change is in rawhide atm 13:50:00 we'll have several weeks of development time after the beta release and that should be plenty for this 13:50:14 just wasnt sure when to push that change into the f26 branch 13:50:25 kalev_: oh, ok! 13:50:32 * ryanlerch was worried that it was too late 13:50:34 #action ryanlerch and kalev_ coordinate to get gnome-backgrounds and new fedora-workstation-backgrounds pushed at the proper time to include post-Bea 13:50:38 #undo 13:50:38 Removing item from minutes: ACTION by stickster at 13:50:34 : ryanlerch and kalev_ coordinate to get gnome-backgrounds and new fedora-workstation-backgrounds pushed at the proper time to include post-Bea 13:50:42 #action ryanlerch and kalev_ coordinate to get gnome-backgrounds and new fedora-workstation-backgrounds pushed at the proper time to include post-Beta 13:51:11 thanks stickster, kalev_ 13:51:12 ryanlerch: kalev_: Anything else on this one? 13:51:22 sounds like not :-D 13:51:22 nothing from me 13:51:41 nothing from me 13:51:48 * stickster holds gavel for 30 sec in case someone else has something 13:51:56 On this, or something else? 13:52:19 on anything otaylor -- go ahead 13:52:47 so, I'm starting to work on some example modules for flatpak applications 13:52:58 #topic Flatpak example modules 13:53:35 And finding some packaging changes that would be useful (simple example, wayland doesn't build currently because of graphviz incompatibility) 13:54:06 I'm currently targeting the f26 package set - partly because that's what modularity WG has been biulding on and f27 is in a lot of flux 13:54:50 What do people think about landing changes into dist-git on the f26 branch during the f26 cycle which *only* are for the module experiments, and not strictly helping for f26 13:55:07 * stickster sucks air in through teeth in a pained sort of way 13:55:45 I think alternativively I could make modules which were hybrid f27/f26 13:55:47 My initial impression is, we're pretty risk-negative about f26 branch at this point. As in, any is bad 13:56:32 Now, zero-day updates maybe? Or even negotiable about early post-Beta period, maybe. I don't think people would be chuffed about anything destabilizing, though. 13:56:36 stickster: It's probably a fair point that I shouldn't be fooling around on what we've released to people in production, even if I *think* it can't break anything 13:57:04 I'm really thinking post freeze - post release, not talking about doing anything that would destabilize the release 13:57:06 Gee, it would be great if everyone had the ability to twiddle around and then do a compose to prove nothing breaks ;-) 13:57:24 But post freeze, people are using things day-to-day - so it's not like we should be casual then either :-) 13:57:30 otaylor: that's probably a fair request 13:57:38 * stickster notes he needs to go run another meeting 13:57:58 otaylor: might be something for devel@ list just to be clear about what you propose 13:58:15 OK - this can be brought up later - I'll see if I can make it more coherent and put it into a ticket 13:58:23 let's take this to #fedora-workstation if we need to delve in, though 13:58:39 * stickster will close now -- thanks, everyone, for coming! 13:58:56 #endmeeting