16:00:52 #startmeeting Fedora Workstation WG 16:00:52 Meeting started Wed Jan 21 16:00:52 2015 UTC. The chair is stickster. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:52 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:01:00 #meetingname workstation 16:01:00 The meeting name has been set to 'workstation' 16:01:07 #topic Roll call! 16:01:22 * mclasen is wrapping up another meeting 16:01:47 * ryanlerch_ is here 16:02:26 hi 16:02:27 * stickster wrapping up elsewhere too, but should be 100% here shortly 16:03:36 * rdieter waves 16:03:54 hi 16:04:06 OK, fully here now :-) 16:04:20 #chair mclasen ryanlerch_ elad661 rdieter jwb 16:04:20 Current chairs: elad661 jwb mclasen rdieter ryanlerch_ stickster 16:05:02 #topic libinput plan 16:05:23 Anyone know if Hans is around on IRC? 16:05:44 * stickster not expecting phutterer 16:05:55 i cna ping hans 16:06:21 * otaylor is here 16:06:40 #chair otaylor 16:06:40 Current chairs: elad661 jwb mclasen otaylor rdieter ryanlerch_ stickster 16:06:49 My question for the agenda is, do we have a consensus on the original plan that was posted to the ML? I believe Peter noted for rdieter and others that it seemed like the touchpad issues could be solved in time 16:07:20 * mclasen has to read up on the 'plan' 16:07:21 * cschalle is here 16:07:27 sorry, not fully informed 16:07:33 I'm here, but also in a conference call 16:07:42 mclasen: I think the original pitch was to add xorg-x11-drv-libinput to the default components in the workstation for F22 16:08:01 hansg: ^ (And understood about the call) :-() 16:08:03 er, :-) 16:08:10 oh, right 16:08:25 and the complication was that kde is not quite ready for libinput yet ? 16:08:36 The original plan was to make xorg-x11-drivers require it, so all products get it, making it part of the default set for workstation was done to give e.g. the xfce people more time 16:09:09 In initially the idea also was this would give kde more time, but then it was brought up that kde should be a first class workgroup citizen 16:09:20 so now we've agreement on doing a patch for kde 16:09:46 Yeah, and I believe rdieter confirmed that a patch would be OK in the interim, with the intent of getting things upstreamed per usual 16:10:05 i think the last i saw from Peter is that he's was in contact with upstream and things were going well there 16:10:24 Peter == whot ? 16:10:32 yes 16:10:45 #url https://lists.fedoraproject.org/pipermail/desktop/2015-January/011396.html 16:10:47 if patching kde seems feasible thats sounds all great to me 16:10:53 #link https://lists.fedoraproject.org/pipermail/desktop/2015-January/011396.html 16:11:41 The best question here is, do we have any members opposed to going forward, then? And who will take care of the component changes required? 16:12:22 no opposition from me :) 16:12:41 I think kalev_ normally does those, but I just want to make sure we track it to done... also I haven't seen Kalev yet. Which means he's the best person to assign it to :-D 16:13:03 I'll add it as a task on the f22 tasklist 16:13:21 that should give us enough of a reminder to see it to completion ? 16:13:29 mclasen: Yup, good enough 16:13:49 oops, sorry for being late 16:13:57 #agreed We can go ahead and make changes as suggested; KDE can carry a patch for now, whot is working with upstream 16:14:07 * mclasen goes to do it right now 16:14:09 #action mclasen Add to F22 tasklist for tracking 16:14:38 Good enough. Let's move on then... 16:15:11 * nirik reads back and notes xfce should hopefully be fine with libinput. Minor patch and thats it. 16:15:27 nirik: Thanks for reviewing! That helps. 16:15:30 ryanlerch_: We missed your thing on wallpapers for a few meetings. The discussion seems underway on the list, do you need time here or can we go straight to the big item for this week? 16:15:52 * stickster doesn't want Ryan to feel sidelined... 16:15:56 hansg: put your name next to it, hope you don't mind 16:16:25 mclasen, that is ok 16:16:29 havent got much feedback on the list yet (on the actual proposal), but lets go to the big item, and talk wallpapers at the end if we get time 16:16:36 otherwise, defer to the list 16:16:42 ryanlerch_: OK. 16:16:50 ryanlerch_, sorry for all the digressions caused :) 16:17:03 #topic Third party applications 16:17:10 #link http://blogs.gnome.org/uraeus/2015/01/19/planning-for-fedora-workstation-22/ 16:17:11 cschalle, haha, all good! they were good points :) 16:17:16 #link http://blogs.gnome.org/hughsie/2015/01/09/finding-hidden-applications-with-gnome-software/ 16:18:13 OK, so the purpose here is mainly for us to discuss more specifically what we want to propose for this change, and that what we propose has some chance of passing (in other words, will survive some FESCo/Council decision) 16:18:26 yeah, so I am happy to draft something more concrete up, but I think it should be fairly clear from the blog etc., where I am aiming, so I wanted to get some intial feedback from the working group before starting to draft 16:19:11 Some folks wisely pointed out the orthogonal spectra of legality and freedom. I think one thing we probably want to do is figure out which quadrant(s) we care about for our proposal. 16:19:38 I got some feedback from matthew miller already for instance about making sure to put in details about inclusion processes for instance 16:20:02 it is essentially another go at something that was reject by the board a year ago, so we'll have to come up with a careful proposal that avoids some of the trigger items 16:20:47 I am personally very much for making it easier to find 3rd party apps, but it definitely requires some careful balancing to make sure the powers that be don't reject it 16:20:55 stickster, yeah, well it doesn't directly answer your question, but my thought was that we for the initial release this gets targted for pick 3-4 interesting applications that represent different sides of the spectrum and use them to figure out the ground rules and practicalities 16:20:59 mclasen: Agreed. I think it will be important to summarize those categories or divisions of what free/nonfree/legal/illegal we are attempting to solve for 16:21:38 I think my contribution on the list can be summarized as: only ask to include free and legal stuff 16:22:43 mclasen: I guess it might be helpful to say whether "free" is "freedom" or "freely redistributable" here 16:23:17 I mean to me there seems to be potential corner cases where things are obviously 'legal', like Google Chrome, yet I don't know if Fedora Legal still wants to review the inclusion of repo data for anything that comes with a EULA? 16:23:19 If we say free is freedom, maybe we don't care as much here, because something like that could be packaged in Fedora or a COPR, which may be a special case 16:23:49 everything that is in a copr should qualify, certainly 16:23:54 s/which/and/ 16:24:13 because we're basically as picky about what we allow in coprs than we are for fedora proper 16:24:21 but do we need to verify the coprs? I mean there are rules about what you are supposed to put in a copr, but there is little policing on that I assume? 16:24:22 Yeah, if it's a COPR it seems like a no-brainer that we *could* include, just a matter of deciding which to do (yes, this goes back to how we make decisions, but let's hold off there for a moment) 16:25:32 cschalle: I'd argue that is "someone else's problem"(tm) (to verify copr content) 16:25:39 cschalle: I'm assuming there is a magic step where we consider the content of the COPR before we propose including it. I'm not mentally filling in that part yet, still trying to figure out if we know what we will *not* propose here in terms of 3rd parties *more* external to Fedora, to narrow down 16:26:06 Will we propose e.g. Flash or Chrome, distributed only by a third party? 16:26:41 Will we propose any rpmfusion, which may have legal issues? (I'm guessing not.) 16:27:14 It will help the proposal to be explicit about things that we're *not* proposing as well -- so that people don't jump to their own conclusions 16:27:54 I'm with mclasen (if I understand clearly), include only clearly legal and free stuff initially 16:28:05 well my wish is to make the list of stuff eventually offered just be a reflection of 'the universe' as opposed to a carefully edited and put together list. The only question is if there are things we have to blacklist for legal reasons. rpmfusion I guess is one thing we cant will not offer the same goes for the hypotecocal 'app to let you track your sales of crack cocain to preschoolers' 16:28:09 that probably means limiting it to copr's only 16:28:24 stickster: hard to do that if you can't even say the name of the repository :-) 16:28:52 rdieter, well we want to offer 'free beer' stuff here though 16:28:56 'app to let you track your sales of crack cocain to preschoolers' <--- uh ... we have no rules against that 16:29:03 unless that is patented ;) 16:29:07 "This proposal does not include offering metadata for any repository that has legally forbidden items, whether it is FOSS or not" 16:29:16 cschalle: then we have to verify things 16:29:26 and interesting category outside of copr that we do want to include is stuff that is shipped by third parties and has to be downloaded from there for legal reasons 16:29:32 mclasen: Something like Flash or Chrome? 16:29:32 stickster, exactly 16:29:37 stickster, openH264 16:29:45 steam? 16:29:56 spotify? 16:30:04 dropbox 16:30:24 I don't know the exact legal/freedom classification for all of those 16:30:45 well eventually all of these should be listed, because it should just be 'what is out there' not about 'what we recommend or suggest' 16:30:58 Flash: legal_to_offer+, FOSS- 16:31:20 or course for some of them there are details to figure out, like for Steam for instance we might need to hosted elsewhere than rpmfusion to be able to list it 16:31:48 as a tangent, we need to inform the user about all these differentiations we want to make 16:32:07 stickster: we could ask rpmfusion to split there repo even more free, freeworld and nonfree or something 16:32:11 so we a) need to have the classification in the repo files and b) have suitable end-user text for each of them 16:32:31 drago01: The only reason something is in rpmfusion is because the legality is questionable. 16:32:49 stickster: no or because its closed source 16:32:49 I don't think thats true for all things in there ? 16:32:51 (Maybe with the exception of a couple required deps?) 16:33:04 its not 16:33:08 drago01: Right -- that would be nonfree, sorry. 16:33:16 oh, I guess steam is there due to the dependency on codecs 16:33:19 its juts a collection of stuff that "is not allowed in fedora" 16:33:20 * rdieter thinks this discussion may be premature, didn't fesco/board explicity block stuff like this before? won't that happen again, or have things changed? 16:33:35 be it for patents, being non foss or not allowed by policy (kmods) 16:33:37 drago01: But yeah, we could ask for that. Let's concentrate on what we can do now, not "if someone else does work" 16:34:00 rdieter: The discussion was based on not much level of detail, or implementation. 16:34:21 It was very conceptual and hand-wavy. Whereas now we can propose an implementation and specific content. 16:34:44 stickster: I guess my point was since "they" (fesco/board) blocked in the past, ask them for specific circumstances where something like this could be allowed, first 16:34:45 making a more concrete proposal may have a better chance, and the board got replaced by the council... 16:35:15 Yeah, although I think it's more about concreteness as opposed to expecting the governance change to magically whoosh away objections :-) 16:35:17 rdieter, well fesco and the board also constantly change, so in any democracy you can always re-open issue after the next election 16:35:47 ok, I just would hate to see a lot of effort spent on something that's dead on arival 16:35:59 So has anyone here actually answered the *concrete* question of what they want to propose to include other than free-and-legal COPRs? 16:36:03 rdieter, well the implementation work is already done since we needed it for RHEL anyway 16:36:45 stickster, my 4 sample apps would be Chrome, OpenH264, PyCharm and Steam 16:36:46 cschalle: ok 16:37:20 cschalle: That sounds like a pretty good start in terms of addressing our "quadrants" 16:37:24 thats refreshingly concrete 16:38:27 in terms of proposing a policy for additions, I would suggest that we promise to not add any repos that fall outside of 'free and legal' without asking first 16:38:36 As noted above, we probably want to be clear we are not proposing legally questionable items 16:38:41 mclasen: *jinx :-) 16:38:47 cschalle: no flash in that list? 16:39:16 flash is slowly dying 16:39:32 mclasen: +1, else conspiracy theorists will assume otherwise 16:39:35 its still alive though 16:39:35 cschalle: on the otherside, seeing the proposal coming up every 6/12 months by the same people doesn't look good either 16:39:51 drago01, well it is a definite addition to discuss once the rules and setup is done, but having done through 5 Months of discussions with Adobe about Flash in RHEL I don't want to make that our testcase here :) 16:39:54 True dat. Flash is still in use quite a bit; you can get by without it more than 5 years ago though 16:40:15 cschalle: ok fair enough 16:40:16 cschalle: Fair enough. Better to hinge on something we know we can get done. 16:40:30 how do we go about proposing this - write a change request ? 16:40:43 concil ticket? 16:40:50 get an ack there first? 16:41:04 well I can draft up a policy doc, the working group iterates over it until we can sign off, and then make the change request up to FeSCO 16:41:52 other tasks to do before we are ready to propose this ? do we need a package with those repos for trying it out ? 16:41:55 or to council, although I think it went through FeSCO the last time 16:42:13 it was escalated up through fesco, yes 16:42:19 mclasen, not really, I mean we can emulate this pretty much with what is already available 16:42:19 FESCo makes sense although we would want to cc someone(s) on council to be up front 16:43:11 We can do that at the proper time 16:43:41 have we solved questions like 'where do you get the pycharm icon' ? 16:43:56 we should make sure that it actually works well for the 4 you want to propose 16:44:16 #proposal We'll propose Chrome, OpenH264, PyCharm, and Steam for our initial policy 16:45:01 mclasen, yeah, I just don't want to go to external people with asks before we have an agreement inside Fedora for doing this 16:45:09 And know how it works... 16:45:18 yup 16:45:26 sounds good to me, I think that's a good starting list and makes it easier for the council to decide if we have a concrete list of apps 16:46:04 well, even if we don't install the repo files by default, having their repos 'ready' will make things appear better in gnome-software (and other appstream consumers) if the user installs the repo manually 16:46:20 cschalle: We will probably want to talk further with hughsie about implementation for user-warning text 16:46:49 I will 16:47:05 stickster, definetly, my idea there is that there is a standard 'fallback' text upstream, but that GNOME Software will look for a translated distro provided file with translated messages and use that instead if available 16:47:09 in fact, I already asked my designers about some of the feedback on hughsies post 16:47:17 We need better text upstream, IMHO; but (maybe more importantly?) perhaps this is something where downstream vendors like Fedora will want to override text to match up with how they position themselves 16:47:27 cschalle: Ha, *jinx 16:47:41 All my ideas are belong to others :-) 16:48:29 Just commented on the list that we should probably list the name of the vendor under the name of the app when searching 16:48:32 cschalle: let's throw XML at it, everyone loves that :-) 16:48:32 I will make sure to talk about that in the draft 16:48:38 so you'd know it's 3rd party before you click on Install 16:48:47 elad661: That's a good idea 16:49:09 there's a bit of a question how much and what quality metadata we can get 16:49:15 So it'd look like Steam \n Provided by Valve Software 16:49:19 elad661: you will not be able to click on install, all 3rd party repos require an extra 'enable' step in the UI which clearly marks them as 3rd party (not against the idea though) 16:50:15 you'd probably want the users to know it's 3rd party even after they passed the enable step 16:50:16 s/on install/to install/ 16:50:19 cschalle: *: Are there other decisions/agreements we need to make here? 16:50:47 stickster, no, I mean anyone feel free to chime in on the mailing list and I hope to have a first draft put up before our next meeting 16:50:55 we just need someone to volunteer for writing a proposal, and iterate it on the list, I think ? 16:51:06 mclasen, already volunteered 16:51:25 #agreed proposal on 4 test cases sounds good to everyone who voiced an opinion 16:51:36 (I used to be in the boy scouts, so I am all about volunteering :) 16:51:45 ok, I'll volunteer to drive the testing/fine-tuning of the gnome-software implementation forward by talking to hughsie 16:51:49 #action cschalle write draft proposal for 3rd party metadata and circulate to WG before next meeting for comment/iteration on list 16:52:09 cschalle: Feel free to call on me for drafting help or once-over editorial pass 16:52:24 stickster, ok will do 16:52:34 #action mclasen Work with hughsie on fine-tuning of gnome-software as needed to support policy draft/agreements 16:52:48 I hope to have this on the fedora wiki quick enough that anyone can start helping with proof reading and editing long before our next meeting 16:53:17 fwiw, you don't need to CC anyone on the Council for teh fesco ticket. i can bring it to their attention as the engineering rep 16:54:22 jwb: That sounds good. I thought of that also, but I can say it here so I *jinx your idea ;-) 16:54:41 cschalle: Awesome. 16:54:53 OK, can we give a few minutes back to Ryan then? 16:54:58 sure 16:55:05 ryanlerch_: Ha, you get 5 min :-) 16:55:13 #topic Wallpaper 16:55:29 so, wallpapers :) 16:55:38 #link https://lists.fedoraproject.org/pipermail/desktop/2015-January/011477.html 16:55:58 ryanlerch_: Despite the immediate OT stuff... I think this is a good idea and probably overdue 16:56:09 #link https://fedoraproject.org/wiki/Changes/WallpapersCleanup 16:56:21 thanks :-) 16:56:38 anyone have any thoughts / questions ? 16:57:18 ryanlerch_, one of the problems you try to fix is to keep the list fresh (as I am reading it), but I don't see that there seems to be a clear way to get new wallpapers in on a regular basis 16:57:19 ryanlerch_: I haven't caught up on the thread this morning -ENOTIME. But were you thinking we would have an election for the WPs to include, or just have some primary stakeholders decide? 16:57:40 cschalle: Every Fedora release there's a supplemental wallpaper "contest" to include new ones 16:57:48 Or at least, there has been for most recent releases IIRC 16:58:00 stickster, yes, that is correct 16:58:15 ryanlerch_: one thought: 1+1+15 is not divisible by 3 16:58:20 stickster, ok, but in the proposal as it currently reads the only new one in a given relase is the new release wallpaper and maybe one form upstream? 16:58:24 #info Supplemental wallpapers have been included for most recent releases 16:58:27 you should add one more background to fill the grid... 16:58:27 #link https://fedoraproject.org/wiki/F20_Artwork/Submissions/Supplemental_Wallpapers 16:58:42 cschalle: I think this refers to just the defaults, is that right ryanlerch_ ? 16:58:57 stickster, cschalle yes, just the defaults 16:58:59 Someone can always elect to install a package of additional artwork 16:59:22 mclasen: 16, sounds just as good to me. Not 13 though. ;-) 16:59:30 ok, but as I originally asked isn't the goal here to keep the wallpapers list a bit fresher, just replacing 1 default each release isn't that 16:59:33 mclasen, :) good point 17:00:02 cschalle: the supplemental list will refresh each release too 17:00:12 * mclasen wonders if this is a good time to warm up the old 'wallpaper channels' ideas 17:00:59 We are out of time unfortunately 17:01:04 ryanlerch_: I did it to you again ^^ 17:01:13 cschalle, IIRC, the original idea of the supplementals was that they would be the defaults for that release. 17:01:26 but that would mean the entire set would change every release 17:01:40 *nod 17:01:45 rdieter, ok, but for someone (like me) who mostly just looks at the default list, the amount of change to it will be very small, especially as the old greatest hits list is not likely to change a lot I would assume 17:02:11 ryanlerch_: embarrassed to ask, but how are supplementals currently distributed ? package ? 17:02:21 the proposal is that this release, we refresh to a set of 15 + 1 + 1 where the 15 doesnt change release per release, but the other 2 do 17:02:46 cschalle: the design team refreshes the supplemental wallpapers every release (afaik), so there should be a good amount of change 17:02:46 backgrounds-extra* i think... let me get the actaul name ... 17:03:08 Do we want to include the supplemental package by default then? 17:03:17 some web-based thing would make so much more sense... 17:03:25 mclasen, f21-backgrounds-extras-gnome 17:04:00 stickster: I assume yes ( ryanlerch_ can clarify if otherwise) 17:04:03 * mclasen drifts off into a different meeting 17:04:08 mclasen: I have to do that too :-) 17:04:28 just a quick note: just sent a question about webapps for developers to the list 17:04:37 ryanlerch_: perhaps we might want to apply some of these clarifications to the change page 17:04:58 I agree with mclasen regarding "web based things". Packages are really unfit for this kind of content. 17:05:03 the page does say "A cleaner set of default choices for wallpapers in Fedora" 17:05:05 the proposal as i put forth wasnt to provide the supplmentals as default, it was to choose from that entire set over the 6 releases we have had supplementals to refresh the basic list that hasnt really changed for ages 17:05:12 aka, ladybug on leaves 17:05:17 *nod 17:05:45 Yeah, I wasn't suggesting otherwise, just trying to clarify, given some of the discussion 17:05:45 elad661, mclasen so if someone installs without internet they don't get wallpapers? 17:06:08 Maybe more like, they get some but can bring more in from another source 17:06:19 ryanlerch_, or maybe a installed subset, but the 'universe' available when online? 17:06:26 what cschalle said. 17:06:29 this is about the *default* choices 17:06:34 *nod 17:06:49 ryanlerch_: the default wallpaper(s) are of course going to be installed locally 17:06:54 #idea Orthogonal -- do we want some non-package source available for more art? 17:07:30 stickster: assumes someone is ready to implement that, orthogonal to the proposal at hand (imo) 17:07:37 #idea Have 16 wallpapers besides the Fedora + GNOME defaults, to fill the grid to 18 17:07:46 rdieter: Exactly 17:08:05 https://debarshiray.wordpress.com/2014/03/18/flickring-backgrounds/ ? 17:08:52 just didn't want discussion of the proposal at hand to get derailed 17:09:23 fwiw, i posted a suggestion regarding wallpapers to the list 17:09:30 ryanlerch_: It seems like no one's opposed (and all are generally in favor) of cleanup, so perhaps we just take the clarifications to the list 17:09:43 ryanlerch_: fwiw, I like it, overdue 17:09:49 the benfit of choosing the 16 from the previous supplementals is that we know they are licenced correctly. they were submitted by fedora community members (not just the design team), ad there is a lot of them to choose from to be able to get a good vareity 17:09:52 basically suggesting that we manage them as a single set, and stop mixing them from different sources 17:10:07 aday: that's a good idea 17:10:09 so they are consistent, and fit with our branding 17:10:33 i'd love to have a set that looks like a set, rather than a jumble of images from different sources 17:10:52 #idea aday suggests managing the wallpapers as a single set rather than from different sources 17:11:19 It might be possible to have some guidelines where our supplemental submissions have a better chance of being in that single set, i.e. being able to turn over a small number per release 17:11:47 isn't f21-backgrounds-extras-gnome already a single set? 17:11:58 aday, what do you mean by a set -- i dont think they choices should be all of the same object, or all of sunsets or something? 17:12:35 rdieter: It is, but we may want something with a more distinct palette, or something like that (not sure of the parameters, just saying it could be a different set) 17:12:47 ryanlerch_: they should be consistent enough to look like they belong together. like, all photos of landscapes, or have a series of abstract images that are variations on a theme 17:13:17 * rdieter thinks that's a good suggestion for the design team picking the wallpapers 17:13:46 that is definiely achieveable from the set of supplementals. 17:15:15 Yeah, whatever happens here, we would want to establish how they get picked, and the Fedora Design team should be heavily involved 17:15:58 * stickster tends to think we could collaborate with them to come up with the theme to suggest for supplemental submissions 17:16:20 That way, what we get as inputs will tend toward the desired goal :-) 17:16:48 But also still encourage people to submit other stuff if they like, and it may still end up in other set(s) whether packaged or elsewhere 17:17:10 ryanlerch_: Can we take some of these ideas to list then? We're way overtime, I'm in another meeting, and need to close this out :-\ 17:17:40 ugh, sorry :( 17:19:34 No problem... I'll close out but we can go to #fedora-workstation for more discussion, too :-)' 17:19:37 #endmeeting