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
> 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:
> 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
> List of proposed MLs to send this summary to:
> 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.
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:
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.
On Sun, Aug 24, 2014 at 11:21 PM, Zachary Snyder
> 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
We already do that. Also, next time please use "Reply to All" to reply
on-list so other people will see your comment too.
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  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
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
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
NetworkManager-l2tp-0.9.8.6-1.fc20.x86_64 requires ppp = 2.4.5, but none
of the providers can be installed. package
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
I was on the 3.12 copr already.
Thanks for putting up the new copr!
Join Fedora! Come talk to us!
Some important talks from Flock:
First, Christian Schaller's "Fedora Workstation - Goals, Philosophy, and
Second, Langdon White's "Fedora for Developers"
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.
Fedora Project Leader
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:
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
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
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)