desktop August 2014

desktop@lists.fedoraproject.org

57 participants
40 discussions

Re: Proposal for every WG to send a short summary *to other WGs directly*
by Josh Boyer 26 Aug '14

26 Aug '14

On Tue, Aug 26, 2014 at 10:46 AM, Honza Horak <hhorak(a)redhat.com> wrote: > Hi working groups members, > > since we have learned on Flock that new Fedora working groups do not > communicate with each other much (or enough), I'd like to propose the > following: > > Every working group will time to time (e.g. weekly) send short summary about > what they did / were talking about directly to mailing lists of other > working groups + to devel(a)fp.o. Really only a short summary with links where > one can find details. > > I tried to collect such info from the meeting logs and mailing lists for the > last few weeks for Env and Stacks WG: > https://lists.fedoraproject.org/pipermail/env-and-stacks/2014-August/000487… > > I found many notes are really worth spreading beyond groups' borders, but it > takes too much time for one person to collect all the information. Thus, > proposing to "do a summary once per group and share with other groups". > > Another benefit would be that Matt would have better content for his 5tiftw. > > I don't think we need to sync about date or frequency, just remembering to > send a direct mail if anything interesting is done/discussed should work > fine. > > List of proposed MLs to send this summary to: > server(a)lists.fedoraproject.org > desktop(a)lists.fedoraproject.org > cloud(a)lists.fedoraproject.org > env-and-stacks(a)lists.fedoraproject.org > devel(a)lists.fedoraproject.org > > Comments, ideas or better solutions are welcome as usually, but I might be > offline until Sunday, so do not expect any answers from me in that time :) I don't have any major objections to this, but I will note that reports stopped being sent to FESCo because at some point they were kind of redundant. "Still working on thing X" every week isn't really something that needs to be sent. So I would avoid a weekly deadline and maybe just post minutes/summaries of the meetings the groups have when there is actually something to communicate. josh

1 0

How about "noatime" now?
by Diogo Campos 26 Aug '14

26 Aug '14

Since Workstation became more "independent", this change would make sense? There are REAL benefits? There are REAL downsides?

3 4

Final products content for F21 pre-release web
by Jaroslav Reznik 25 Aug '14

25 Aug '14

Hi all! Websites team is asking for final text for the pre-release F21 web as it has to be translated to other languages in advance. For current content, take a look on staging web [1]. Please confirm it or provide final version asap. More details what's still needed for Alpha release is at [2]. Thanks Jaroslav [1] http://stg.fedoraproject.org/en/get-prerelease [2] https://fedorahosted.org/fedora-websites/ticket/267#comment:18

3 2

Please update F21 packages with fixes before the Gnome test day on 2014-08-28
by Ankur Sinha 25 Aug '14

25 Aug '14

Hi, The Gnome test day is scheduled on 2014-08-28. It'll be nice to have the lastest fixes in F21 by then to ensure that testers don't hit fixed bugs and end up filing dupes and such. Here are some bugs that I ran into that have been fixed, and updates to F21 would be really appreciated: https://bugzilla.gnome.org/show_bug.cgi?id=735334 - mutter crashes on dual monitor setups - update already pushed https://bugzilla.gnome.org/show_bug.cgi?id=734945 - gnome-themes-standard https://bugzilla.gnome.org/show_bug.cgi?id=735311 - eds and google These are just ones that I ran into and am, therefore, aware of, of course. If there are any other fixes, they'll all be nice to have. https://fedoraproject.org/wiki/Test_Day:2014-08-28_Gnome_3.14 -- Thanks, Warm regards, Ankur (FranciscoD) http://fedoraproject.org/wiki/User:Ankursinha Join Fedora! Come talk to us! http://fedoraproject.org/wiki/Fedora_Join_SIG

1 0

Tasklist changed over to list taks by releases
by Christian Schaller 25 Aug '14

25 Aug '14

As discussed during Flock I would move things around in the tasklist to map to where we expect given features to land. I have now done so as can be seen here: https://fedoraproject.org/wiki/Workstation/Tasklist Be aware that Fedora 23 is currently the equivalent of 'anything no scheduled for F21 and F22'. There are items on the F23 tasklist that might never get done unless new contributors step up to the plate to handle them. Combined with the plan for the new bi-weekly working group meetings I hope this will help improve the information flow for the product. Christian

1 0

Re: Maybe it's time to say goodbye to start.fedoraproject.org?
by Elad Alfassa 24 Aug '14

24 Aug '14

On Sun, Aug 24, 2014 at 11:21 PM, Zachary Snyder <sadin(a)fedoraproject.org> wrote: > One thing i know #! (a Debian variant) does with their firefox is they > configure it so that it has the bookmarks bar filled with links to the > project homepage, about page, and community page. Maybe thats something we > could do as an alternative if we do decide to get rid of > start.fredoraproject.org? > > We already do that. Also, next time please use "Reply to All" to reply on-list so other people will see your comment too. -- -Elad Alfassa.

1 0

inbound SSH allowed for default install of Fedora Workstation?
by Chuck Anderson 23 Aug '14

23 Aug '14

On Sat, Aug 23, 2014 at 09:52:11AM -0500, Michael Catanzaro wrote: > Our understanding is that client and server development WILL work out of > the box, unlike F20. The goal is that very few users ever need to > configure the firewall. Our configuration can be seen at [1] and it > looks sufficiently permissive to me. (Is there something else we need to > address?) Whereas in F20 I spent much frustrating time trying to figure > out why my network programs worked on other Linuxes but not Fedora, in > F21 everything should just work, unless you're trying to use a system > port. I frankly cannot think of any reason I would ever want to open > firewall-config. > > Michael > > [1] > http://pkgs.fedoraproject.org/cgit/firewalld.git/tree/FedoraWorkstation.xml Why is SSH in this list? Is it a common thing for a developer, student, or hobbyist to want to connect back INTO their workstation from a remote location? If so, is it common that they'd want a CLI session vs. a full graphical session (Remote Desktop)? I don't think it is obvious to some of these audiences that the local account login password also allows remote access. I see people set a simple password for a "throwaway" or "test" laptop for example, but unfortunately this exposes them to being hacked via SSH. Or is the SSH service shipped turned off by default in Fedora Workstation?

2 2

Gnome 3.14 copr on F20
by Ankur Sinha 23 Aug '14

23 Aug '14

Hi, I just read Matthais' post on the planet and couldn't wait to try out the new *shiny* gnome packages from the 3.14 copr. Unfortunately, there seem to be some breakages: dnf --refresh --best update gives me: Error: nothing provides gnome-shell >= 3.13.2 needed by gnome-shell-extension-common-3.13.2-2.fc20.noarch. nothing provides gnome-shell >= 3.13.2 needed by gnome-shell-extension-common-3.13.2-2.fc20.noarch. package NetworkManager-l2tp-0.9.8.6-1.fc20.x86_64 requires ppp = 2.4.5, but none of the providers can be installed. package evolution-data-server-3.12.3-1.fc20.x86_64 requires libgdata.so.13()(64bit), but none of the providers can be installed. package gnome-shell-3.12.2-1.fc20.x86_64 requires libmutter-wayland.so.0()(64bit), but none of the providers can be installed. package gnome-shell-3.12.2-1.fc20.x86_64 requires libmutter-wayland.so.0()(64bit), but none of the providers can be installed. package NetworkManager-l2tp-0.9.8.6-1.fc20.x86_64 requires ppp = 2.4.5, but none of the providers can be installed Omitting the --best flag doesn't work either. It wants to reinstall evolution-data-server and errors out saying: Error: Transaction check error: package evolution-data-server-3.12.3-1.fc20.x86_64 is already installed I was on the 3.12 copr already. Thanks for putting up the new copr! -- Thanks, Warm regards, Ankur (FranciscoD) http://fedoraproject.org/wiki/User:Ankursinha Join Fedora! Come talk to us! http://fedoraproject.org/wiki/Fedora_Join_SIG

6 18

Developer focus for Fedora workstation
by Matthew Miller 22 Aug '14

22 Aug '14

Some important talks from Flock: First, Christian Schaller's "Fedora Workstation - Goals, Philosophy, and Future" <https://www.youtube.com/watch?v=LYtJZBgOrKw> Second, Langdon White's "Fedora for Developers" <https://www.youtube.com/watch?v=COAeCYSxEQk> I'm particularly interested in feedback on the second one. A good discussion started at the conference, but we ran out of time. Overall, it is somewhat different from the "Workstation" idea I had in mind at last Flock and with the _initial_ .next proposal, but I think Langdon and others arguing for this more dramatic approach have convinced me. What do you all think? The impact on F21 will be small, but a clear direction here can guide our marketing, and, not so long from now, the production of F22. -- Matthew Miller <mattdm(a)fedoraproject.org> Fedora Project Leader

25 68

Guidelines draft: Apps and launchers
by Elad Alfassa 21 Aug '14

21 Aug '14

Hi all. Since apparently we can't remove anything from default without having a "policy", and we can't ask packagers to fix their software either, I have to write this message. Apparently, not including a package by default is seen as "punishment". So, instead of doing actual work on bugfixing or debugging Fedora 21, or working on our website so it'll be ready for release time, I have to write this email message. I assumed the whole idea of Fedora.Next was to reduce bureaucracy and making sure we ship a high quality product. Apparently, I was wrong, and the point of Fedora.next seems to be *increasing* bureaucracy and having to discuss and write a policy for every one line commit we do. If you are out of the loop of the recent events, look at this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1131248 --------- Now, enough bitter sarcasm, here is my draft: In the following policy, I differentiate between "app launcher" and "app". An "app launcher" is a desktop file+icon that is shown in the application view, clicking on it would launch the app. An "app" is an application as defined by the GNOME 3 HIG (link TBD when HIG is published) As always in policies, mandatory items are marked with the words "must" and "must not", the rest is nice-to-have. App launchers in Fedora workstation *must*: * Have a unique 64x64 launcher icon (the same icon MUST NOT be used for one default launcher). * Have a matching High Contrast icon. * Have a name that is either short enough to not be elipsized by the shell or immediately recognizable even when elipsized. * Have a comment field in the desktop file with a one line summary of what the app is. App launchers in Fedora workstation *should*: * Launch software that is an actual app - see the GNOME 3 HIG on the exact definition (link TBD when the HIG is published) * If the app is not an actual app, it should have the appropriate desktop file categories to be placed in the Sundry folder in GNOME Shell. Apps in Fedora Workstation *must*: * Not depend on / pull in other apps OR app launchers. * Have exactly *one* app launcher - ie. two launchers to two separate parts of the same app is not allowed. * Be packaged separately (subpackages are okay) form other apps OR plugins. * Installable and removable independently from within GNOME Software, unless part of the "core applications" set, in which case they must NOT be removable. Default apps in Fedora Workstation *should*: * Have appdata metadata (soon to be turned into a must). * Have a good reason for being included in the default set, especially if not considered part of the core desktop experience by the GNOME upstream. * Start in under than 10 seconds (on modern hardware). An app or launcher that fails to complies with these guidelines MUST NOT be included in the default install. Furthermore, if an app that doesn't follow this policy is include by default, it should be considered a Final Release blocker until the app is fixed to conform the policy or removed from the default install. ---- Each line in this policy has a very good reason behind it, and I hope I don't have to explain each one of them separately. Following this simple policy will ensure a polished and good user experience in viewing, launching and installing applications. Note that I'm being a bit lax on the requirements here. I'd place "launch an actual app" in the "must" column but we tried that before and it didn't work due to (silly) internal project politics, as people want things like release notes have a launcher by default. Feel free to reply with your opinion, and put it in the wiki somewhere when it's officially approved by the WG (which, to remind all involved parties, I'm not an official part of) - -Elad Alfassa.

10 26

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

desktop August 2014