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

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

On Thu, 2005-03-24 at 09:53 -0800, Bryan J. Smith wrote:
> Fedora Core has seemingly continued this route in releases to date ...
> I had hoped that Fedora Core 4 would be the CL4.2 I envisioned, the
> ".2" of the CL4 series which would go on to be the Legacy supported
> version alongside the EL4 commercial product... But the reality is
> that there has to be a general guideline, there has been such in Red
> Hat Linux before, and right now the understood and trusted guidelines
> is starting to hold very poorly in Fedora Core.

Because _so_many_ people (other than maybe Steven Pritchard and Dean
Henrichsmeyer) are missing my point, please understand I am _not_
complaining about Red Hat, Red Hat's decisions on the greater Fedora
Project and how Red Hat _does_still_directly_ support the development of
Fedora _Core_, alongside greater Fedora Project developments.

What I am _explicitly_ complaining about is how Red Hat, who large does
still control the development of Fedora _Core_ (like Red Hat Linux
before it), is not sticking with the tried'n true 0-1-2 revision release
model for these "Community Linux" releases.  I had hoped that by Red Hat
stating Fedora was a "return to its roots" it meant that Fedora _Core_
was going to be like Red Hat Linux 4.x, 5.x, 6.x and 7.x, with a trusted
0-1-2 (possibly 3, or even just 0-1 sometimes) like before.

Right now there is absolutely no trust of that model in Fedora _Core_,
at least as far as the Fedora Core 3.90 release stands.  Now Red Hat
_could_ retro the GCC change back so Fedora Core 4 is the "CL4.2" I
envisioned, just like they did with Red Hat Linux 7.3.  Or if they
don't, they should at least use a versioning that indicates major
changes were made.

In other words, if I could retro-label Fedora Core releases, I would
have called them:  
- Fedora Core 3.2 (Fedora Core 1)
- Fedora Core 4.0 (Fedora Core 2)
- Fedora Core 4.1 (Fedora Core 3)
- Fedora Core 4.90 (aka 5.0 Test 1) (Fedora Core 3.90 aka 4 Test 1)

All I'm asking is that Red Hat adopt a versioning guideline, because
that guideline is sorely needed to track ABI compatibility -- especially
against Red Hat Enterprise Linux.  We had this before with Red Hat Linux
-- even going back to not only Red Hat Advanced Server/Enterprise Linux
2.1 (EL2), but even the original "Enterprise" in Red Hat Linux
6.2"E" (EL1).

But if Red Hat wants to continue to change each and every GCC, GLibC or
whatever "core" ABI affecting program/library on a whim in every new
"revision" of Fedora Core, then my view is that every Fedora Core
version should be considered the same as a ".0" release of Red Hat
Linux.  Which alienates its consideration by myself.

Merely dedicating my time to the greater Fedora Project (Fedora Extras,
Legacy, etc...) does not help because they are still affected by these
Fedora Core decisions made by Red Hat and the Fedora Steering Committee.
In the same regard, dedicating my time to cAos, who maintains their own
RHEL and FC releases has the same issue, unless they fork (which is not
good either).

I have always loved Red Hat as a company, it's entire philosophy of the
unique balance of business and source -- GPL to the anal power.  I just
wish they wouldn't do away with the trusted revision release model of
their "Community Linux" in Fedora _Core_ today.  I've always supported
lots of distros, and I have never left Red Hat, but Novell-SuSE is
making me reconsider the balance of "Community-Enterprise" _version_
relationships, because Red Hat doesn't seem to care about that all-
important mapping anymore.


-- 
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@silug.org with
"unsubscribe silug-discuss" in the body.