Re: An Open Letter to Red Hat: Guidelines for Fedora Core

["Bryan J. Smith" <b.j.smith@ieee.org>]

On Thu, 2005-04-07 at 08:22 -0500, Danny Sauer wrote:
> Updates are periodically released for each Fedora snapshot, right?

First off, Fedora is not a "snapshot."

Secondly, Red Hat treats the last 2 Fedora Core releases as "Current"
until the next Test 2 comes out.  As long as they are current, they
support them, including testing patches before they are released.

As I've pointed out regularly, this is because Red Hat knows that
because of the Community-Enterprise duality, if they do not see the
maturity of the Community release, it will affect the quality of the
Enterprise that is based on it.

Once something is tagged "Legacy," then it is up to the community to
offer support.  In many cases, Red Hat still releases packages, but it's
up to the Community to test and support them.  I've seen stuff get
"Stuck" in "Testing" on Fedora Legacy.  Which is why people like Steven
have suggested people donate time to Fedora Legacy.

> Wouldn't it be just as effective to look at the release date of the
> given snapshot, and then look at the dates and changelogs to see how
> many fixes have been released, how quickly, and if they were fixing
> big problems or just adding features?  From that information a user
> could determine for himself how he felt about the stability of a
> fully-updated Fedora vX.

This has nothing to do with updates or guaranteed stability -- I'm
talking about using a designation on ABI compatibility.  Red Hat started
canning updates and guarantees on even Red Hat Linux long ago (before
Fedora Core), as they started to drop Red Hat Linux (now Fedora Core) as
a product.

Yes, for proper configuration management, one must track RHL/FC and RHEL
updates.  I do this for a living, and teach others how to as well.  As
long as a Community release is "Current," Red Hat does an excellent job.
When a Community release reaches "Legacy," the updates still flow
seemingly as good as any "independent RHEL Rebuild," but there are no
guarantees.

But this has *0* to do with my comments.  My comments are aimed at
brining revisioning back to Fedora Core, like Red Hat Linux before it.

> It seems that such a scheme would be even more reliable than basing
> the assumption on an arbitrary numbering scheme that doesn't
> officially mean anything.

You are, yet again, assuming I am suggesting "updates/stability" with
the revisioning scheme.  I am not.  Let me repeat this in context ...

VERSIONS MEAN *NOTHING* WHEN IT COMES TO UPDATES/ASSUMED STABILITY

But they can and do tell people when there are only slight change, and
when there is a major change.  Changes reduce compatibility, so
typically stability as well.  If I change the GCC and GLibC, there is a
change that older code won't build and run.  Not until those changes
have had awhile to proliferate and be accommodated.

This is the essence of how RHL has _always_ been revisioned.
Fedora Core should follow suit too.
Why it can't makes me scratch my head based on other distros that do.

> I mean, by somewhat arbitrarily presuming that x.0 is dangerous,
> x.1 is getting there, and anything from x.2 on is totally stable,

No, not stable, but "established."  A x.2 that uses the same GCC/GLibC
as a x.0 means that there has been 12 months of use of that GCC/GLibC,
so many programs will have likely been modified to work with it, as well
as more bugs fixed in those releases.

No guarantee, but a "common sense" way to revision distributions.

> you're (the general you - not just Bryan) basically assuming that things
> get more stable as time passes without major changes.

I don't know about stable.  But in general, compatibility and
reliability improve because anytime you "freeze" something, you stop
focusing on the next version and focus on resolving issues with the
current.

> So, wait a few months after a Fedora snapshot

Ugh, pleeze point me to where Fedora is developed on a "snapshot"?

> is released and then upgradee + install all of the available updates. 

And I assume I already don't do this.  ;-ppp

I waited 3 months into Fedora Core 2 before doing such.
But then I upgraded to Fedora Core 3 only 3 weeks after its release.

Why?

Fedora Core 2 made _massive_changes_.
Fedora Core 3 made far less.

They should have been tagged something like Fedora Core 4.0 and Fedora
Core 4.1, respectively.

> Put "3.2" in /etc/fedora-release or where ever they keep the verion
> number (the last Red Hat-esque distro I installed was Yellow Dog), and
> sleep better at night. :)

That's what I do for many people.

I've found my own documentation is getting to the point where I could
write a book.  I'm going to call it "Red Hat Configuration Management."

It details many things -- from the ABI Compatibility to Release Control.
In reality, it's not really much different from what companies like
Progeny (founded by Debian's founder) consult on -- the reality that a
"product" doesn't guarantee good release control, only you can.

> That reminds me - this is amusing:
> http://funroll-loops.org/
> --Danny, whose cars are all V8-powered ;)

Yes, that's where I got my analogy from (I saw it awhile back).


-- 
Bryan J. Smith                                  b.j.smith@ieee.org 
---------------------------------------------------------------- 
Community software is all about choice, choice of technology.
Unfortunately, too many Linux advocates port over the so-called
"choice" from the commercial software world, brand name marketing.
The result is false assumptions, failure to focus on the real
technical similarities, but loyalty to blind vendor alignments.



-
To unsubscribe, send email to majordomo@luci.org with
"unsubscribe luci-discuss" in the body.