Fedora and the System Administrator -- I'm probably distracting people here, but ...

[Bryan J. Smith]

Quoting "Michael K. Johnson" <johnsonm at redhat.com>:
> First of all: It did not jump to "3.0".  There's no ".0" in it.  Just
> "Red Hat Enterprise Linux 3" with no decimal or decimal-ish part.

My ignorance, my apologies.

So from a product marketing standpoint, it is just "3".  Will Red Hat maintain 
an internal/technical designation for revisions at least?  E.g., 3.x???

<soap box>
I know the industry has this "dot-fobia" right now, but I like it _much_better_ 
than the whole "service pack" nomenclature.  But tag it as you will.  ;-ppp
</soap box>

> There are lots of changes.  I think the more interesting questions
> would probably be what *hasn't* changed.  Yes, NPTL is in.

Okay, that would explain the move to 3.  I just miss those "good old days" when 
I could could on the major version to stick with the same GLibC/GCC.  I guess 
that's what we now have in a single 18 month RHEL release, instead of 3 x 6 
month RHL releases.

> If I tried to present the new features here I'd miss lots of them,
> even in my area of the kernel.

Understood.  I think NPTL says a lot.

> I know that our sales force has the capability to talk about the
> features that have been added.

As always.  ;-ppp

At least you don't send out your sales people and have them tell people that 
they are "engineers."  That's the #1 reason why even MCSEs dislike Microsoft.

> We're not going to avoid deploying new technology in Fedora just
> because you want to be able to build Fedora packages on RHEL.  :-)

No more than you have done with Rawhide in the past, I know.  But if I was Red 
Hat management, I'd have to believe that by seeing 3rd party packages built to 
my commercial product, I'd sell more commercial product.  But they know 

Which brings me to the culmination of a point I wanted to bring up before.

Does Red Hat see either ...
  1)  Two tags in Fedora -- one for Fedora, one [subset] for RHEL, or
  2)  Expecting community software projects to release a RHEL version 
themselves, all while working with Fedora to release one for Fedora

I'm not trying to tell Red Hat what to do.  After all, unlike Debian, you have 
to support what you ship.  So that means you're limited in what you can ship.  
But I think #1 might be in its best interest, from a commercial perspective, to 
provide a framework for this, to help sell your own RHEL products.

Because the problem with #2 is why people prefer Debian, and might not move to 
Fedora en masse.  #2 still means there is no community built around RHEL, which 
means there is less incentive for the regular user to purchase it (or worse, 
purchase SuSE Linux Personal/Professional instead).

If Red Hat does not consider this a market consideration, then I'd understand 
(and I'm _not_ deamonizing Red Hat here).  But I think other people have hit on 
it.  There needs to be a new "consumer" between the new Fedora "enthusiast" and 
the RHEL "business" products.

So I've suggested that Red Hat consider help supporting a "tag" in Fedora, even 
if it is a subset, of popular packages for its current RHEL release.  That 
would help Red Hat sell more RHEL WS/ES boxes.  I leave it up to Red Hat to 
decide if the costs of doing such are worth the potential increase in sales of 
RHEL WS/ES.

> If you look historically, the changes have tended to be small and
> manageable most of the time.

Right.  As long as GLibC/GCC doesn't change, most things are accomodated.  And 
given that RHEL release are supposed to be 18 months apart, this is basically 
what we had with the 3 x 6 month model of X.0 - X.2+. 

> But let's take a concrete example of a major change.  Let's say, for
> example, that RPM was changed so that you didn't have to list patches
> in one place any apply them in another; that you could say something
> like
> %patch(foo-1.0-fixblah.patch) -p1
> in the prep section, and RPM wouldn't need a separate
> Patch0 foo=1.0-fixblah.patch
> line to know that the foo-1.0-fixblah.patch file existed and should
> be packaged.
> We wouldn't wait until a version of RHEL had that capability to start
> to use in in Fedora packages.  If you wanted to rebuild the modified
> packages, you'd have to modify the spec files.

And I understand that.

But I also see that preventing people from buying RHEL, because it is no 
different than what they had before.  Now Red Hat could choose to hope that 
another party picks up that end, or the Fedora community themselves.  But given 
why Fedora now exists, I want to believe Red Hat might consider "unofficially" 
(i.e. unsupported) maintaining its own "tag sub-set" of the Fedora repositories 
that easily build on their current version of RHEL.

Do you see where I'm coming from, just a recommendation?

> fedora-devel-list is where we'll be talking about any such changes.

FYI, I promise to avoid posting discussions like the above, unless I'm directly 
supporting a package myself (not likely anytime soon -- as I'm too busy "cert 
whoring" until probably mid next year, long story ;-).

> And it's simply not a promise we're making.

Oh, I guess I should clarify.  I'm not expecting Red Hat promise such.  It's 
not feasible for Red Hat to do so.

If there is one thing I _know_ of Red Hat, they make small promises and deliver 
_more_ than most people expect.  So that's all I'm hoping for here.

> It might work on a technical basis, opportunisticaily, though if
> you replace RHEL3 apps with hand-built ones you'll want to check
> your SLA wording to see what it does to your support level.

The idea here is to _not_ replace anything that RHEL ships.  Only _augment_ 
what is in it.  That would make SLA a nightmare for Red Hat, and be self-
hindering to support such an effort.

Which is why I'm calling it a "tag subset."

So if that means you can't run the latest GNOME, or a GNOME app that requires 
the latest GNOME, that's totally understandable.  I think I made that known in 
the other post.


-- 
Bryan J. Smith, E.I.  mailto:b.j.smith at ieee.org  http://thebs.org
------------------------------------------------------------------
There is no greater ignorance than the popular American environ-
mental movement, which focuses on the most useless details.  Be it
recycling the world's most renewable resource or refusal to use
proven CFC insulation on launch vehicles, no lives will be spared
in the further pursuit of, ironically, harming the environment.