-----BEGIN PGP SIGNED MESSAGE-----
Apologies for the slightly alarmist $SUBJECT, but I want to make sure
that this gets read by the appropriate groups.
During today's FESCo meeting, there was the start of a discussion on
how to approve new Products into the Fedora family. As part of this,
it naturally strayed into discussion of what we do about Spins as they
Several ideas were raised (which I'll go through below), but we didn't
feel that this was something that FESCo should answer on its own. We'd
prefer community input on how to handle spins going forward.
So, in no particular order (because it's difficult to say which
questions are the most important):
1) Are Spins useful as they currently exist? There are many problems
that have been noted in the Spins process, most notably that it is
very difficult to get a Spin approved and then has no ongoing
maintenance requiring it to remain functional. We've had Spins at
times go through entire Fedora release cycles without ever being
2) Should Spins be eliminated entirely in favor of Fedora Remixes.
The effect here would be that Spins are no longer an official part of
The Fedora Project but are instead projects unto themselves which are
permitted to consume (possibly large) portions of our tools, packages
and ecosystem. Maintenance and upkeep of these spins then becomes
entirely the responsibility of the downstream community that
constructs them and has no mandatory draw on Fedora's marketing,
ambassadors or quality assurance resources.
3) Should Spins be considered Products-in-development? In other words,
should we only approve Spins that are targeted or destined for
"promotion" to a fully-supported Fedora Product? This is a nuanced
question, as it means different things for different Spins, for
example Spins focusing on a target-audience (Security Spin, Design
Suite Spin) vs. Spins focusing on a technology (LXDE Spin, MATE-Compiz
3b) If we treat Spins as Products-in-development, what do we do with
those Spins that don't fit that criteria?
I'm sure there are other questions that people will come up with on
this thread, but this should provide a good framework for the discussion.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
-----END PGP SIGNATURE-----
As the subject suggests, Fedora 22 will require applications to have a
long description to be shown in the software center. We're introducing
this change so that we can show a powerful application full of
high-quality content, rather than what we have now which is a equal
mixture of awesome and sadness.
If you're interested you can see the number of applications with
appdata without installing gnome-software from rawhide here:
(warning; huge generated HTML file).
A lot of unmaintained or unloved applications will be removed (which
is a totally good thing, we don't want new users choosing buggy and
crashy apps), but there are also a lot of applications there that we
probably want to save. Note that I don't want the packages removed
from Fedora; users can still use the command line to install them,
just not show them in the 'Software' GUI.
"Saving" an application (so that it still appears in the software
center) is just a matter of either:
* Convincing upstream to ship and install an appdata file
* Installing an appdata file from the Fedora package into
/usr/share/appdata (if upstream is dead / unwilling to add the file)
I've written a bit about the AppData status on my blog,
and so far over 200 applications ship AppData in Fedora 21. That's a
long way from what I'd like to see, but it's going up at about 1% per
month, which is encouraging.
KDE/XFCE doesn't ship gnome-software - however Apper does parse the
appdata in KDE, and we also want to show awesome KDE/XFCE applications
in gnome-software so this really applies distro-wide.
Comments welcome, thanks.
What should one do if the SW he is trying to package produce only
unversioned *.so files? I'm currently trying to package LMDB  as
possible alternative for BerkeleyDB in Fedora, and the hand-written
makefile produce only liblmdb.so.
I'm trying to persuade the upstream to change it and start to do it
properly, however if that fails, what can I do with it on my end?
Thanks for answer,
Jan Stanek - Red Hat Associate Developer Engineer - Databases Team
I really enjoy working with ssh on Ubuntu just for this simple reason,
they have user friendly ssh fingerprint collision messages:
$ ssh root(a)192.168.1.1
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
Please contact your system administrator.
Add correct host key in /home/valent/.ssh/known_hosts to get rid of
Offending RSA key in /home/valent/.ssh/known_hosts:8
I really miss this feature when I return back to Fedora.
How hard would be to make this behavior default for Fedora also?
If time permits I'd like to do an upgrade of ICU to 52.1 next week,
which leads to the usual soname bump.
As quite a lot of packages are affected by this, is anyone objecting and
can point out a better time for the upgrade?
If not, I'll probably announce it on Monday and do the upgrade on
LibreOffice Calc developer. Number formatter stricken i18n transpositionizer.
GPG key ID: 0x65632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A
Support the FSFE, care about Free Software! https://fsfe.org/support/?erack
Apologies for the late notice everyone, but as i've been head of heels
in tons of other work the past week and quite a few folks are either
traveling or attending FOSDEM this weekend we're canceling the meeting
Next week we'll have to see with a lot of people being at DevConf in
Brno/CZ whether we can do a meeting or not, but i'll send out an notice
on Thursday at the latest.
Sorry again for the late note today.
Thanks & regards, Phil
Philipp Knirsch | Tel.: +49-711-96437-470
Manager Core Services | Fax.: +49-711-96437-111
Red Hat GmbH | Email: Phil Knirsch <pknirsch(a)redhat.com>
Wankelstrasse 5 | Web: http://www.redhat.com/
D-70563 Stuttgart, Germany