----- Original Message -----
> My personal opinion is that we ought to try not disrupting the release
> If some features miss the release train, it could wait 6 monthq (and,
> I disagree with dropping the whole server products).
> Fedora.Next is a big change in our model, our priority is to release
> F21 and get some feedbacks so we can adjust the plan.
The thing is - server guys thinks, that without roles API it would
not be Fedora.next. One can argue, that Fedora.Next is creation of
products, not completion of products although.
I can be for delay with a real action plan for roles framework delivery,
I'd be against slipping just for "we need time, we don't know how
much and what we're going to do and when". In such case, it would
make sense to release limited preview of Server product or even
skip it for release.
Probably what we need for products is the same as we do for spins -
readiness checklist and we should be able if product is ready for
release or not.
> Delaying F21 anymore is quite risky for us, I'd rather have a less
> ambitious release than getting stuck.
> devel mailing list
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
On 06/11/2014 04:37 PM, Stephen Gallagher wrote:
> I forgot to open a ticket over the last week, but the Server WG has
> identified that completion of its core task (the Server Role API) is
> likely to need a little extra time. This is a blocker to release, so
> we figured it would be best to ask FESCo to modify the schedule in
> advance, rather than forcing a slip at the end.
> I'll bring this up in Open Floor, unless you want to add it to the
> formal agenda.
How much time do you think you'd need to complete the Server Role API?
With my Workstation WG hat on, I'd very much like to avoid pushing back
the schedule. We already skipped one whole release; if we slip F21 it's
going to negatively impact how users perceive the Workstation, and make
it harder for Workstation developers to work on the code upstream.
At the very least, please don't do a quick decision on today's IRC
meeting and allow some time to discuss this with other WGs.
An alternative to slipping would also be to skip Server this release
cycle if it's not ready. Could try again in 6 months.
Should Firefox stay the default browser in Fedora Workstation?
I know it's powerful, it has a lot of extensions, and it's popular. But
it's integration with our desktop is lacking and getting worse all the time.
Here's a list of things Firefox lacks in Fedora:
* GPU acceleration
* Integration with the desktop's geolocation services
* On that note, geolocation doesn't work at all in Fedora's firefox at
* Integration with the desktop's notification system
* Support of url scheme handlers (this used to work)
* UI that matches the rest of the desktop (without installing 3rd party
theme and extensions)
* GTK3 support
* High-DPI support
* Touch input support
Some of those issues are being actively worked on, other have incomplete
patches in upstream's bugzilla with nobody working to finish them, and some
of them seem to be issues that will never be solved (such as making the UI
feel more "native" to GNOME).
Meanwhile, Epiphany (GNOME Web) keeps getting better and better, perhaps we
should consider it as the default?
I am in Fedora Rawhide but even if I have installed the dnf-plugins-core
package I cannot use the copr
Failed loading plugin: copr
No such command: copr. Please use /usr/bin/dnf --help
So in response to the ongoing discussion about Firewall functionality and the desktop we had a call at the end of last week with some representatives from both
the desktop and firewall development teams, trying to figure out a good compromise and a way forward. I hope people can take the time to look over the ideas we discussed and let us know if you think it is a workable solution.
On the call was:
We had a wide ranging discussion going from what is doable in the Fedora 21 timeframe to what we want from a firewall solution in the long run, what the setup is like on other operating systems, the tradeoffs between security and usability, API and adoption, ease of sharing versus unintended sharing and different corner cases where the different models might break down a bit.
We all agreed on the following core principles
* We want users to be as secure as possible
* We want users to have their privacy protected as well as possible
* We want users to have a good experience using our products
* We want users to be able to use services such as DLNA, Chromecast, Avahi and more without having to search on Google, and more often than not be told that the fix is to disable the firewall.
* We all agree that there is no perfect solutions on offer here. Just a range of different tradeoffs. A system with a running firewall isn't secure nor is a system without a firewall insecure. Instead they exist on a continium of 'more secure' and 'less secure'.
The challenges seen:
* With the current default a lot of services don't work out of the box because the firewall silently blocks them
* There doesn't seem to be any non-expensive way for the system to detect that a service is running and being blocked by the firwall.
* There is very limited use of the firewalld API for doing things like port unlocking and similar due to it being a predominately Fedora and RHEL only solution currently
* Some application developers who do look into using the current API find the API hard to use
* The current NetworkManager UI to change zones is both maybe a bit hidden away and also the Zones options listed there are not intuitive or documented in the UI.
Plans for Fedora 21
* The Desktop team will look into creating a UI that asks you when you connect to a new wireless network if you consider it trusted or not. Exact wording of the question and look of dialog etc. will need to be worked out. This setting will be remembered for that network. If user say trusted the zone used will be 'trusted', if not trusted then current default will be used. Should be simple enough to not confuse users, yet improve their security on public networks.
* Other connection types will keep the current default which sucks a bit for your home ethernet, but we don't currently have a good way to identify your ethernet connection and popping up a dialog every time you connect is
probably a worse user experience than having to google a bit.
Matthias started a prototype of this already here:
Long term plans
* Work with NetworkManager team to see if we can come up with a way to identify ethernet connections in a similar manner
* Look into proposing a new DBUS API for firewalld
* We will keep talking to see if there are more granular approaches that can be developed as we go forward. For many cases the trusted/untrusted question is a bit to simple. For instance you probably trust your work network, but that doesn't mean you want to share your beach vacation photos on the office network.
* Look into using the zones descriptions somehow in the NetworkManager Zone setting UI to make it a bit more understanable than just a list of names. FirewallD team will work on making the descriptions internationalizable.
Matthias filed two bugs related to this:
https://bugzilla.redhat.com/show_bug.cgi?id=1091067 split off zone
configuration in subpackages
https://bugzilla.redhat.com/show_bug.cgi?id=1091068 overprotected api
since i cant find anything new on this topic. im gonna ask . when is
3.12 gonna be pushed to the Fedora repo's? or is it still in
Discussion? if it is can someone point me to where i can follow the
conversation about this please.
I guess there must be a reason for this, but it's odd that Fedora 20
requires authentication to uninstall software, but not to install
(signed) software. It's great that I don't need a password to install
stuff, but why do I need a password to get rid of it? I might be stuck
with software I later decided I don't want after all. If removing
applications is considered a security hazard, then I think
authentication should be required to install as well. (And if the user
is an administrator, maybe the password prompt is not needed at all.)
Alternatively, I should just be able to uninstall something I installed