leading vs. bleeding [was Re: Maybe it's time to get rid of tcpwrappers/tcpd?]

[Michael Catanzaro]

On Tue, 2014-03-25 at 09:24 -0400, Matthew Miller wrote:
> I agree with Harald here. I think some people have always wanted it to be,
> but Fedora never really has been chartered to be "bleeding". To quote the
> "first" foundation more fully:
> 
>   First represents our commitment to innovation. We are not content to let
>   others do all the heavy lifting on our behalf; we provide the latest in
>   stable and robust, useful, and powerful free software in our Fedora
>   distribution.
> 
> Note "latest in stable and robust", not "latest bleeding edge". There is
> supposed to be a balance here.

I think Fedora is hitting that balance relatively well when it releases
new distros. There are always packages with serious bugs, and there are
always packagers that choose to ship development snapshots, but for the
most part, new releases are not the problem. I do not consider a new
Fedora release to be any less stable than comparable distributions. On
the contrary, I think the QA team does a very good job of finding and
resolving blocker bugs, a process no other comparable distro has.

The problem is that stable releases don't stay stable. The updates pipe
turns on prior to day one, and maintainers can release whatever they
want onto the distribution. We see unjustified major version updates
because someone requests a backport of something shiny and new, and with
them come major new bugs, or even major dependency issues.

The existing update policy [1] does a good job of describing what is
appropriate for a stable release update. It's notably much more lenient
than any other major distribution. You cannot get even a minor (bugfix)
version update into Ubuntu/Debian/openSUSE/(Mageia?) just because: you
usually need to pick a change that you really want, and backport just
that change. In contrast, minor version updates are fine for Fedora: our
update policy only prevents updates to major releases with new features,
and even then, qualifies this with language like "if at all possible."

The existing update policy does a bad job of describing when an
appropriate update is suitable for release. There's really no good
reason a noncritical update can go straight to stable after less than a
week in updates-testing, for example. The existing update policy is also
not properly enforced. (I could give examples, but I don't much see the
point in picking on individual packages here: suffice to say that I
don't think FESCO is asked to approve all updates that require
approval.) Lastly, there aren't enough automated checks on the updates:
an update that accidentally adds a dependency on a new graphical program
should be caught automatically, for example.

Ideally, there would be someone other than the package maintainer who
has to press the Release Update button: not to be an update Nazi, but to
make sure the basic rules are followed, and to catch updates that aren't
justified by the changelog.

\$0.02

[1] https://fedoraproject.org/wiki/Updates_Policy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140325/479c5f37/attachment.sig>