Fedora 20 (yes, F20).

Thorsten Leemhuis fedora at leemhuis.info
Mon Sep 13 18:57:57 UTC 2010


On 09.09.2010 00:24, Máirín Duffy wrote:
> Think for a minute or two. What do *you* think Fedora should focus on
> for F15 and F16? How about F17? F18? F19...or... F20? What should F20
> look like, how should it be, who uses it.... at least, for us to have
> succeeded towards achieving our mission as a project?
> Okay, hold that thought.

I'm not that active in Fedora these days -- partly because Fedora seems
to more and more develop into a direction I don't like much. The later
is the reason why I'll bit and answer this; but I write it here and not
on IRC, as I think it's a lot easier to lay out thoughts like those
below in a mail.

Here we go:

 * latest kernels and all the userland packages with drivers
(gutenprint, hplip, xorg-drv-*, sane-backends, ...) should go out to
users as testing update within a few days after they got released and
out as regular update within roughly three or four weeks after they got
released. That way users won't have to wait months to make newly
released hardware work with Fedora, as those hardware will often require
new and improved drivers that are part of new kernels, xdrivers, ...

 * cooperate even more closely with upstream: (1) try harder to not
include patches which are not upstream yet, (2) make upstream better
aware of the problems distributions face (see also next bullet point
below), and (3) if upstream ships a new version then normally sent it
out to users as testing update a few days after it got released and as
regular update within something like three weeks. This scheme needs a
bit of flexibility depending on how good and sane the upstream in
question works. Something like "kde 4.0.0" of course should not have
immediately replaced kde 3.x for each and everyone. Another example:
firefox 4.0.0 might better be shipped as testing update only till
firefox 4.0.1 comes out; especially software that is not supported
upstream anymore (for small software with only a handful of developers
that'll most often include "x - 1" and older releases) should be updated
to the latest version to make sure upstream is interested in bug reports
for our users

 * for packages that properly honour above upstream policy do only
accept packaging bugs in Fedora; everything else should be moved or
directly reported upstream. Then it can get solved there (with
involvement of the Fedora maintainer ) and will make upstream aware of
the problems distributions and their users face; that is better than
package maintainers of dozens or hundreds of distribution trying to fix
and work around the same bugs or limitation, as that results in lot of
wasted work

 * Okay, yes, grated, there are users that don't want updates like the
ones I outlined at the first two pullet points. Those IMHO are better of
with CentOS/RHEL, but support for consumer hardware is those sometimes
is not the best.

 So to not ignore those users we should maintain two "current" releases
(in parallel to rawhide); one that is maintained in a more rolling
release like scheme similar to rawhide; it should contains up2date
software (like outlined in the first two bullet points), but normally
*not* contain any (pre-)alpha or beta code (like rawhide does). Such a
distribution of course would be a bit more moving and up2date then
Fedora is these days. But that is something some people want afaics; for
those that find such a scheme to dangerous maintain a second "current"
release in a similar way to how OpenSuse and Ubuntu maintain their
distribution today: Mostly bug fixes only.

 * have a official sanctioned 3rd party repo and work with it way more
closely than Fedora does today, to make sure it can do things properly
Fedora can't or doesn't want to do; that should even include things
Fedora doesn't like, to make sure that repo can provide a distro that is
based on a unmodified Fedora, but offers some of those things that
people like on Ubuntu (easy installation of those crappy proprietary
drivers for example)

 * have a official sanctioned and supported external side for docs
targeting users, to make sure that side can mention things from the
official sanctioned 3rd party repo without risking legal problems

 * sudo or something like similar with a compatible "sudo" command by

That's all that sprung to my mind right now. HTH


P.S.: I'd really would have liked to write "integrate CentOS into the
Fedora project and make it our LTS release" as a bulled point, but I'd
guess then even more people  would have thought "Thorsten finally went
completely mad" after reading this mail  ;-)

More information about the advisory-board mailing list