[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: How can I update from Shrike to Fedora ?



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, 28 Sep 2003 20:34:35 -0500, Mike Vanecek wrote:

> > [Recycling the reply I posted to redhat-list and fedora-list just a 
> > few minutes ago. Why the separate cross-post?]
> 
> Because not everyone subscribes to all three lists and I want to get the
> perspective and feedback from those with more knowledge and experience that I
> have.

There's no way to avoid further cross-postings now. Because postings
like that, which are ripped out of context, confuse the reader. Taking
a discussion to a different list where no related discussions take
place and where you miss the comments from Red Hat employees, is a bad
idea. The right place where to discuss the future of Red Hat Linux
would be fedora-list redhat com and maybe fedora-test-list redhat com
(but that is devoted to the test release and less to general
discussion). Not even considering those subscribers who consider
cross-postings rude.

> > Can you explain this question a bit? No part of what you quoted gives
> > a hint on what makes you think that "Fedore Core 1" will not be what
> > was expected to become Red Hat Linux 10.
> 
> The poster said:
> 
> > Unless something has changed recently..very recently...having apt or
> > yum work to do dist-upgrade like behavior is not something thats
> > getting a lot of Fedora Core development attention. You can
> > certainly try to do it, becuase both yum and apt have the ability to
> > do this sort of thing...but if it goes wrong...your bugs might not
> > be a high priority. Bug testing effort is best spent on issues
> > developers want tested...and to-date I haven't seen much interest
> > from the development side to make upgrading between releases with
> > apt a high priority. 
> 
> I am trying to plan for what action will need to be done due to the demise of
> RHL. Some have suggested that Fedora will be a logical replacement. Others
> have said that yum/apt might be used in place of up2date. Still others have
> suggested that redhat network will be migrated to Fedora.

Uhm. No idea where you've taken those rumours from. And I still don't
see what this has to do with the subject line and the quoted part
above. If you have questions, I'd rather open a new thread. It seems
you've subscribed just recently without skimming over the archives.

Anyway. Let's get a few things straight. First of all, up2date is part
of Fedora Core 0.94. There is no indication that it would go. RHN
channels are available as well. RHN will also serve Fedora Core final
release plus Updates with the usual priority access for paid accounts.
As you can read at http://fedora.redhat.com it might be that a Fedora
Extras RHN channel will also be an option. Would make sense to make
available at RHN as much "good stuff" as possible.

Up2date itself already supports apt/yum repositories. An enhanced
redhat-config-packages tool is planned (as one can read in the
installer screens). There are no plans to replace up2date with apt-rpm
or yum. (Where did you hear about such plans? Any quote available?)
But those alternative package utilities will be helpful for building
and necessary for accessing 3rd party repositories (even though
up2date supports apt/yum, too). That's why yum has been added to the
distribution already.

> The overall tone of the discussion does not seem consistent with Fedora being
> a redhat linux equivalent product.

I still fail to see what this has to do with the subject line and the
quoted message. There are concerns that the planned product life cycle
of Fedora Core (see http://fedora.redhat.com) is not enough. Yet it
remains to be seen whether the community won't support the product for
a longer period. There are concerns that Fedora Core -- compared with
Red Hat Linux -- will move closer to the bleeding edge and result in a
less stable distribution. Most of this is speculation. Some of the
documentation suggests that the modified update strategy will result
in more bug-fix updates (in form of new packages) compared with the
Red Hat Linux (which has been seeing mostly back-ported security
fixes). This can also turn out to be a good thing.

> If that is the case, then one might want to
> start a serious look for a replacement.

But there have been several related discussions already on the
fedora-* lists. Why take this to other lists in form of a confusing
reply?

> I need a stable 12-18 month release supported by something like up2date. It
> use will not be in a production environment, but it is not intended to be
> bleeding edge either.
> 
> Some have suggested that we wait to see what develops. The exchange, however,
> seemed to imply that waiting might not be a good strategy.

I think you've misunderstood "that exchange" completely. It explains
that so-called "dist-upgrades" with apt-get, yum or up2date have not
been a supported upgrade path and are unlikely to be taken into
consideration. Hence if such a dist-upgrade fails for you, it's your
problem (apart from that, there won't be any phone/web based support
from Red Hat for Fedora Core anyway). It doesn't matter whether it
works for some users. Those upgrade paths don't see any kind of
special or official testing. The official upgrade path is with
Anaconda and CD/bootdisk. A similar thing are the repeated questions
on beta-to-beta or beta-to-final upgrades which are not supported
either.

Back to your quote:

> I need a stable 12-18 month release supported by something like up2date.

Without a comment on the current pricing of Red Hat Enterprise Linux,
without knowledge of what products Red Hat has in the queue, and
without knowledge of how the Fedora Project will develop, your message
does not give enough input for discussion.

- -- 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/d6B50iMVcrivHFQRAtPdAJ0YUlT6MNUrzku9KtNgA3DRuBumBQCePWiE
s42p5gGK2l2RqwH2UU2KNmE=
=XdxU
-----END PGP SIGNATURE-----




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]