workstation
LOGS
16:01:23 <stickster> #startmeeting Fedora Workstation WG
16:01:23 <zodbot> Meeting started Wed Mar  4 16:01:23 2015 UTC.  The chair is stickster. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:23 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:01:27 <stickster> #meetingname workstation
16:01:27 <zodbot> The meeting name has been set to 'workstation'
16:01:33 <stickster> #topic Roll call!
16:02:08 * mclasen_ clocks in
16:02:41 <jwb> i am present
16:03:34 * jsmith lurks
16:03:40 * rdieter waves
16:03:53 <kalev> hello
16:04:28 * ryanlerch is here
16:05:19 <stickster> #chair mclasen_ jwb rdieter kalev ryanlerch
16:05:19 <zodbot> Current chairs: jwb kalev mclasen_ rdieter ryanlerch stickster
16:06:41 <stickster> Who are we missing? I believe we should see cschalle otaylor, not expecting juhp
16:07:26 <stickster> OK, sorry for delay guys, I had numerous critical pings coming out of some phone calls, ready to go now :-)
16:07:34 <stickster> #topic Privacy policy
16:08:21 <stickster> This is more FYI -- there is a pending issue with the Fedora privacy policy not covering some apps where Fedora is the upstream, e.g. ABRT
16:09:08 <stickster> I had a conversation with spot aka Fedora Legal, and we agreed I would help by drafting some changes and getting review by real legal eagles
16:09:51 <stickster> spot is really buried right now trying to cover numerous roles, so it would be tough for him to get it done quickly, which is why I offered to help
16:10:24 <nirik> stickster: would that include mention about the geoip stuff too?
16:10:34 <ryanlerch> is the privacy policy here workstation-specific? or just the general Fedora one?
16:10:37 * nirik thinks that might be good even if it's not a big issue.
16:10:47 <mclasen_> cschalle should be here
16:10:54 <mclasen_> at least he claims he is
16:11:05 <stickster> ryanlerch: It should be general, because it's possible for people to install e.g. ABRT in other products
16:11:18 <stickster> nirik: Actually the interesting thing is GeoIP may be covered already in the existing policy.
16:11:32 <stickster> nirik: But that's something we'll confirm, for sure
16:11:55 <kalev> I am not sure it needs to be general, we could just cover a subset of package we install in the default workstation install
16:12:20 <kalev> and make some statements about the privacy within that subset of packages
16:12:21 <nirik> stickster: cool. ping me if you need any info on how that stuff works.
16:13:13 <stickster> nirik: I will, that will likely be very helpful, so thanks
16:13:23 <mclasen_> stickster: I don't think it covers geoip
16:13:40 <mclasen_> it talks about remembering your geographic location if you have a fedora account
16:13:56 <stickster> mclasen_: Let's not debate it here in the meeting at that level, we can discuss later, and I can explain why I don't think that's correct
16:14:25 * nirik definitely would like to see it more detailed in any case, but yeah.
16:15:05 <stickster> I'll go back to the thread and some info I got from Bastien to pull in all the relevant questions first, to make the draft of changes more effective
16:15:38 <stickster> This is something I feel qualified to do from previous work in legal areas (both Fedora and elsewhere)
16:15:41 * mclasen_ shuts up
16:16:32 <mclasen_> I will say though: the more legalistic we make this document, the less useful it will be for linking to it from the ui
16:16:42 <stickster> #action stickster Pull together relevant issues for current privacy policy, draft changes somewhere public
16:17:29 <stickster> #info We'll also figure out whether this needs to be part of the legal doc as opposed to a more generic information page
16:18:04 <stickster> mclasen_: I suspect you're right
16:18:17 <stickster> Anything else on this, or OK to move on?
16:18:59 <stickster> #topic F22 Alpha release announcement
16:19:05 <stickster> #link https://fedoraproject.org/wiki/F22_Alpha_release_announcement
16:19:27 <stickster> #info stickster threw some notes into the page for Workstation, and mclasen_ was editing
16:20:02 <stickster> This was more a FYI item... This doesn't need to be a huge, detailed accounting of all features since this is the Alpha announcement and not the Final one that goes out to numerous outlets
16:20:29 <stickster> A bullet list will probably suffice. But it would be good to make sure we don't either leave out important things or make too much noise about smaller ones.
16:20:37 <jwb> stickster, s/products/editions
16:20:53 <jwb> or i can change it i guess
16:20:58 <stickster> jwb: I only wrote the Workstation part, but feel free to ... yeah :-)
16:21:53 <stickster> #info If anyone else has edits, have at it :-)
16:22:06 <stickster> Any questions/issues on F22 Alpha release announcement before we move on?
16:22:58 <stickster> #topic Visual issues
16:23:34 <ryanlerch> okies, so the only real one is the wallpaper cleanup feature request i proposed -- http://fedoraproject.org/wiki/Changes/WallpapersCleanup
16:24:00 <ryanlerch> it is basically to have a newer, cleaner set of default wallpapers
16:24:10 <cschalle> +1 :)
16:24:17 <stickster> +1
16:24:18 <mclasen_> seems like a 'just do it' item to me
16:24:54 <kalev> sounds like a really nice thing to do :)
16:25:13 <stickster> ryanlerch: I think the page just needs [[Category:ChangeReadyForWrangler]] to move on... technically it's past the change deadline, but (1) we surely want this release's supplemental wallpaper anyway, and (2) the risk is extremely low
16:25:49 <stickster> jwb: Do you see any issue, beyond the exception needed?
16:26:13 <jwb> no, not really
16:26:53 <rdieter> ryanlerch: one wrinkle, does this work imply some/all of the existing supplemental wallapapers are going away?  (if so, does that mean folks upgrading from previous releases will end up with a blank desktop?)
16:26:59 <stickster> ryanlerch: Any other concerns with the feature that we might have missed?  Is there already a plan for how to choose the wp's?
16:27:14 <sgallagh> The wallpaper change can technically get in under the blocker process, as  I understand it
16:27:28 <ryanlerch> the main thing is i'm not sure i have the packaging know-how to clean up the old ones -- i think they are being pulled in from GNOME packages
16:27:40 <sgallagh> Because there's an alpha blocker criterion necessitating that the default wallpaper must be different from the two previous releases at that point
16:27:46 <sgallagh> (It need not be final, but must be different)
16:27:59 <ryanlerch> sgallagh, this isnt for the *default* though
16:28:04 <sgallagh> ah
16:28:26 <ryanlerch> sgallagh, i have done a quick placeholder wallpaper for that
16:28:33 <sgallagh> ok
16:28:38 <jwb> the fact that we have an alpha blocker on wallpaper is amusing to me
16:28:38 <mclasen_> ryanlerch: packaging wallpapers is really not the right thing to do, just like packaging fonts... but we'll be happy to help with the mechanics (halfline and me have long expericence cutting down wallpaper packages)S
16:28:40 <sgallagh> Sorry, carry on then
16:28:53 <ryanlerch> rdieter, the idea is that the supplementals will still be there
16:29:10 <ryanlerch> he just need a pool of good images to choose some defaults from
16:29:17 <ryanlerch> *we
16:29:29 <stickster> mclasen_: I don't think we want that to be the only -- or even preferred -- source, but certainly we need something in the default
16:29:49 <mclasen_> yes
16:30:21 <stickster> If there's a feature to import from some sources, we could get future supplemental wp's saved to that source so they show up as a matter of course
16:30:51 <mclasen_> I believe there's flickr support in the background panel
16:30:51 <ryanlerch> stickster, as for choosing the defaults from the supplementals -- i was going to get the design team to choose those
16:31:21 <stickster> mclasen_: I'm running F22 and I don't see it, but that could be something I haven't done on my end perhaps
16:31:26 <stickster> ryanlerch: Makes sense to me
16:32:03 <mclasen_> stickster: set up a flickr account in goa ?
16:32:50 <ryanlerch> stickster, other than the wallpapers not really much else from me -- other than the new gnome-shell theme looks amazing :)
16:33:08 <mclasen_> ryanlerch: I asked about black vs gray
16:33:16 <stickster> mclasen_: Ha, that's probably it :-)
16:33:27 <mclasen_> and it is intentional (I didn't really doubt it was...)
16:33:44 <stickster> I love the new theme too
16:34:19 <ryanlerch> mclasen_, ah ok -- yeah i'm not too invested in changing it -- it just seemed a bit out of place to me at quick glance
16:34:25 <cschalle> maybe once we get the Fedora account integration into GOA we could have a 'Fedora Wallpapers' service or something
16:35:09 <mclasen_> ryanlerch: the argument for the blackness of the top bar is the same as always
16:35:30 <mclasen_> and it doesn't really apply to the other shell chrome, which is why they are now different
16:35:44 <cschalle> maybe if owen gets his power saving and brightness control changes in people will not be able to notice the difference between grey and black anyway ;)
16:35:53 <stickster> I always thought the blackness was there to make it feel like either part of the monitor bezel or otherwise less-usable space
16:36:12 <mclasen_> yeah, the top bar is background, basically
16:36:15 <stickster> cschalle: Not a bad idea re wallpaper service.
16:36:41 <ryanlerch> mclasen_, but the lockscreen topbar is transparent / grey -- that is where i got really confused
16:36:55 <stickster> #action ryanlerch Add category to wiki page, get Design team choices together for supplemental, and consult with the WG folks for package changes needed
16:37:09 <stickster> #link http://fedoraproject.org/wiki/Changes/WallpapersCleanup
16:37:58 <mclasen_> ryanlerch: can't really explain that, other than that it looks cool
16:38:00 <cschalle> stickster, yeah, the Fedora account integration has kept being pushed down rishi TODO list due to lack of features, but maybe if we combine ABRT and a wallpaper service it starts to add up and become worthwhile to work on
16:38:09 * stickster sheepishly realizes he didn't even notice the difference
16:38:34 <cschalle> stickster, probably just means you preserve battery by running a decent brightness level :)
16:39:26 <ryanlerch> stickster, that is me done, FWIW
16:39:35 <stickster> okies ryanlerch
16:39:45 <stickster> #topic Third party repos
16:40:11 <stickster> #link https://fedoraproject.org/wiki/Changes/DisabledRepoSupport
16:40:19 <stickster> #info stickster posted Change page as suggested in thread
16:40:32 <cschalle> change page looks good to me
16:41:12 <stickster> One thing to note here is this changes nothing practically in Fedora. A policy change (plus following package changes) would be needed to actually make the feature work. As is, it'll work for any downstream remixers that use it
16:41:54 <jwb> it's an interesting way to write the Change
16:42:27 <stickster> I think repos that package a -release type package might find some marginal utility.
16:42:30 <cschalle> stickster, ok, I thought the policy change was part of the change, I mean what is the point of making a Change anyway without that? I mean the software we ship add/change features all the time without it becoming Fedora Change requests
16:43:14 <jwb> separating policy from mechanism is how i view the existing page
16:43:19 <stickster> jwb: That's correct
16:44:07 <stickster> cschalle: What you're talking about is a change to the policy page at https://fedoraproject.org/wiki/Third_Party_Repository_Policy
16:44:50 * rdieter assumes so
16:44:54 <cschalle> I mean its not like hughsie will patch out the feature in the code based on a FeSCO or Council decision, so the only real question is if we will use the feature or not in fedora
16:44:57 <mclasen_> yeah, not sure I see the point of having a change for the mechanism - its already in f22, after all
16:45:11 <stickster> mclasen_: Now you see my point from the thread. ;-)
16:46:00 <jwb> stickster, i think the point everyone else wanted from the Change process was including the policy.
16:46:12 <jwb> because yes, otherwise this is fairly silly
16:46:33 <stickster> The policy was put out by FESCo, but also says the Board (now Council) needs to weigh in on any change to the third party bit. I've asked around some folks like mattdm and if we want a change we need to make a case for how it better satisfies Fedora mission.
16:46:34 <rdieter> it's not 100% silly, it's still useful (for remixers)
16:46:43 <stickster> rdieter: Agreed, or I wouldn't have bothered
16:47:19 <sgallagh> Alternately, the Council needs to be convinced that the mission needs adjusting.
16:47:36 <rdieter> within legal limits, of course
16:47:51 <stickster> Mission: "The Fedora Project's mission is to lead the advancement of free and open source software and content as a collaborative community."
16:48:05 <stickster> Vision: "The Fedora Project creates a world where
16:48:11 <rdieter> the Third_Party_Repository_Policy makes it clear searching repos needs legal vetting
16:48:13 <stickster> free culture is welcoming and widespread, collaboration is commonplace, and people control their content and devices."
16:48:21 <mclasen_> the mission is fine, its the interpretation that needs adjustment
16:48:45 <rdieter> so I really don't think there's much to be haggled about here
16:49:32 <jwb> a suggestion
16:49:45 <stickster> rdieter: The policy is actually unclear wrt. needing legal vetting. It says we need it for free/libre software when we don't know if it's licit
16:49:53 <sgallagh> mclasen_: Right, sorry. I was thinking of the Foundations rather than the Mission
16:50:14 <stickster> rdieter: The issue on the table is enabling nonfree/nonlibre software that is licit (Chrome, Steam)
16:50:20 <jwb> if you want to convince people that shipping such repos (disabled or otherwise) is important in fedora, then perhaps phrase it in exactly that way
16:50:39 <jwb> "we'll get more users/contributors because XXXX" or "this will promote free software because YYYY"
16:50:43 <cschalle> stickster, it is also about enabling free software not fitting the Fedora packaging guidelines
16:51:09 <rdieter> stickster: ok, fair.    this isn't clear? "Repositories that enable a specific piece of free software may be pointed at in the same way as COPRs. However, they must be approved by both FESCo and Fedora Legal first."
16:51:10 <jwb> cschalle, the existing answer to that is Coprs, which is covered
16:51:13 <stickster> cschalle: True, although COPR does that in part now so that seems less aproblem.
16:51:28 <stickster> IOW what jwb said ;-)
16:51:36 <jwb> and also rdieter :)
16:51:39 <cschalle> jwb, ok, so we are free to ship repo files for any COPR we want?
16:51:57 <stickster> cschalle: Have you read https://fedoraproject.org/wiki/Third_Party_Repository_Policy ?
16:52:00 <rdieter> cschalle: no
16:52:15 <jwb> The COPR Repositories can provide RPMS with .repo files pointing to themselves because Red Hat is the provider and assumes liability
16:52:18 <jwb> RPMS with .repo files pointing to COPR repos cannot be included in the main Fedora repository per FESCo decree.
16:52:21 <jwb> the second one says no
16:52:30 <cschalle> Edward Boras example on the mailing list is part of what we want to cover here
16:52:38 <jwb> however:
16:52:48 <kalev> rdieter: are we free to search for software in any coprs, provided that we ask if the user wants to enable the copr before installing from there?
16:52:49 <jwb> "Application installers in the main Fedora repositories may search COPR repos for applications to install as long as they explicitly ask the user to enable the copr repository as noted in the introductory section. "
16:53:02 <jwb> kalev, i would say yes
16:53:03 <kalev> jinx, that's the section I meant :)
16:53:19 <cschalle> ah ok, cool, ok so COPRs are fine under this new mechanic then
16:53:20 <rdieter> kalev: my interpretation is: no
16:53:24 <mclasen_> it also says " RPMS with .repo files pointing to COPR repos cannot be included in the main Fedora repository"
16:53:29 <rdieter> not without a policy change
16:53:38 <jwb> rdieter, the policy explicitly allows that
16:53:47 <sgallagh> mclasen_: I suspect that if we revisit this with the new mechanism, that may get revised
16:54:05 <mclasen_> lets hope so, because this is pretty much exactly what we're asking to do
16:54:06 <rdieter> jwb: oh, sigh, of course, next line
16:54:30 <stickster> cschalle: As long as we expect the user to visit the COPR repo and pick up a .repo file, or mycopr-release.rpm there -- then yes, COPRs are fine
16:54:36 <sgallagh> mclasen_: FWIW, I think that line was transcribed wrong.
16:54:36 <mclasen_> I guess adding an 'enabled by default' in that line might save it
16:54:49 <sgallagh> IIRC from the original discussion, it was that it couldnt't be shipped *enabled*
16:55:02 <sgallagh> Which at the time amounted to having no purpose
16:55:04 <stickster> cschalle: But that basically goes for just about *any* other repo, including unmentionables.
16:55:39 <mclasen_> stickster: we don't expect the user to do that - thats basically the 'just google it, dummy' line
16:55:43 <stickster> sgallagh: OK, so that sounds like an immediate clarification we'd like.
16:55:43 <rdieter> that really doesn't seem consistent though, and now we're getting back to why clarification is needed, I think.  ha
16:55:58 <cschalle> stickster, no, I mean the way I (and I assume jwb and sgallagh) reads the current policy, shipping .repo files for coprs are fine as long as they are disabled by default
16:56:28 <stickster> cschalle: Yeah, I was having trouble reading the convo, and just picked up the error in the policy text
16:56:33 <rdieter> the only specific case where searching is explicitly *not* allowed is: Third party repositories that host diverse pieces of software (a repository like Fedora before it became a Red Hat community project, for instance) cannot be searched or enabled.
16:57:00 <mclasen_> thankfully, we're not asking to include any of those
16:57:06 <rdieter> which to *me*, means other cases *are* ok
16:57:08 <stickster> So can we agree that we need FESCo to clarify this? Because this one change sgallagh notes above makes a pretty big diff for COPRs.
16:57:25 <stickster> It doesn't make things better for other repos but it's a start.
16:57:49 <sgallagh> stickster: I can bring it up during Open Floor at today's meeting.
16:57:57 <sgallagh> Starting in about 60 minutes
16:58:08 <rdieter> stickster: ask for clarification if you want, but I was confusing myself between simply providing a repo/metadata and searching. I think the policy on searching is clear (per my prior 2 comments)
16:58:23 <cschalle> yeah, because with such a clarification we can at least start adding things like PyCharm and maybe RStudio
16:58:36 <kalev> searching is implemented by accessing the repo metadata though
16:59:48 <rdieter> stickster: ok, the specific clarification needed is if there is a policy difference between enabled .repo files and disabled .repo files
17:00:17 <rdieter> but I'll guess there must be, otherwise it's impossible to do any searching
17:00:28 * mclasen_ getting pulled away into another meeting
17:00:33 <kalev> no, the specific clarification needed is if we can ship repo files for performing search (search is explicitly allowed by the policy)
17:00:53 <rdieter> I think kalev agree, though we're using different words :)
17:00:53 <kalev> otherwise if we just ask if we can ship disabled repo files, I am sure what the answer will be
17:00:57 <kalev> good :)
17:01:01 <stickster> rdieter: And also whether that difference also applies equally to (1) COPRs, (2) third party repos of software similar to Fedora, or (3) third party repos of specific licit software
17:01:27 <stickster> kalev: mclasen_ ^ cschalle ^ Make sure that I stated that extra clarification correctly.
17:01:29 <rdieter> stickster: the "repo of diverse software" case is already clear imo.
17:01:39 <rdieter> stickster: everything else is fair game though
17:01:42 <stickster> rdieter: I think it is too. But whether that's the same answer as all 3 needs to be explicit
17:02:25 <stickster> (1) and (3) seem like they could be within grasp to help users/developers migrate to our platform more easily
17:03:12 <stickster> #action sgallagh rdieter Ask for clarification on third party policy in FESCo meeting
17:03:26 <stickster> OK, sorry for going overtime folks. Thanks for being here and for good discussion!
17:03:31 <stickster> #endmeeting