fedora mission (was Re: systemd and changes)

[Gerald Henriksen]

On Mon, 30 Aug 2010 23:11:06 +0200, you wrote:

>A typical developer wants the dependencies of the software they are
>working on to be _very_ up to date - probably not the upstream
>development version, but the upstream maintenance version with _all_
>current bug fixes.  Waiting 6 months for a bug fix does not make sense -
>at that point the developer would be tempted to build the new version
>locally.

While I admit I haven't followed things very closely, I don't believe
anyone is saying don't issue bugfixes.  What is being said is don't
upgrade versions just because something newer and shinier comes along
in the middle of a release.

So in other words, dependency 1.6 to 1.6.1 is okay as it is likely a
bug fix, but 1.6 to 1.8 is not okay because it is a new release.

>So, web developers want latest httpd/PHP/Rails/MySQL; GNOME developers
>want latest gtk/libgnome*; and so on.

I wouldn't be so sure about that.

If I was developing a web application I would want my version of
httpd/PHP/Rails/MySQL to remain stable - the last thing I want is a
bug to appear in the application I am writing and have to wonder if it
is a problem with my code or did the update in my framework change
something on me.

Similarly, if I develop a desktop app then I want gtk and the Gnome
libraries (or Qt and the KDE libraries) to remain stable under me so I
don't have to wonder where the errors are coming from.

If on the other hand I am actually developing Gnome, then yes I want
the latest gtk etc., but that is why a project like Gnome has jhbuild
to make it easy for the developers to keep to the bleeding edge of the
Gnome stack without disturbing everyone else.

>Similarly, everyone who cares about the tools they use daily (which
>developers tend to), wants the best versions of these tools, as soon as
>it is practical.  So, newest version of emacs/vim/kdevelop/...

Again, as a developer I would disagree.  Unless the latest
emacs/vim/debugger etc. offer a new feature that is going to save me
time I want things to remain consistent.  Upgrading brings the risk of
a new bug that interupts my ability to work.  This is something that
should only be done at a new release, so there are no unexpected
surprises to me as I try to balance keeping my system secure with bug
fixes and actually getting the work I want to do done.

>Saying "use rawhide" is not helpful, because rawhide is very often
>broken.  A "stable" release that breaks a specific component for a few
>days is acceptable - if this is not a component one uses for
>development, it doesn't matter; if this is such a component, one knows
>about it well enough to be able to revert an update or to contribute a
>fix.

Ironically you have actually just described rawhide.  Despite the
reputation rawhide very rarely breaks for more than a day or 2 at a
time, the usual issue is more that upgrades won't happen because of
dependency issues that can take a while to sort out.  But those don't
make the system unusable.

>When a large number of Fedora contributions are not paid to do so, they
>naturally write a distribution _for themselves_.  Why would they not?
>
>That means that updates will be frequent; few maintainers would push
>updates they consider too risky, but some risk is acceptable.  The
>"updates firehose" for components one does not much care about is a
>minor risk, compared to the "commit firehose" for a mid-size program on
>which one collaborates with two or more other people.

The problem is there is too much to a system that you do care about,
whether it be your desktop environment, an email program, X, the
kernel, etc. that end up getting pulled out from underneath you as you
try to do your work that isn't related to them.

>The result is a distribution on which it is reasonably easy to develop
>current software, and a distribution on which one might not update
>critical system updates on the night before giving a presentation on a
>conference (FWIW, I can't recall a really bad updates experience).  That
>doesn't seem to be a bad tradeoff - for a developer.

So lets see, you are going to give a presentation or attend a
conference, where you will likely be using an unsecured network with
many threats that likely don't exist in your home or office
environment, and you are saying that because we have a distrubition
where anything can change and possibly break things you think it is
okay that you have to forgo critical system updates that might prevent
your system from being hacked?  How can that be viewed as an
acceptable tradeoff?

>What Fedora advertised is "..., Features, First" - that's a developer's 
>distro; Fedora was never "M million happy users, growing X% annually".

Actually, Fedora was.  Fedora initially followed on from Red Hat Linux
and was stable between releases, but this has gradually changed with
time.