Fedora Core 3 Transferred to Fedora Legacy

[Hans Kristian Rosbach]

On Sun, 2006-01-22 at 14:41 -0500, Jeff Spaleta wrote:
> On 1/22/06, Les Mikesell <lesmikesell at gmail.com> wrote:
> > Can we have a show of hands from the people who think a new
> > user should have to download an iso image full of bugs that
> > have been fixed for most of a year that may prevent the
> > install from working and that will require a gig or so of
> > additional downloading to fix if the install succeeds?

I think what he is saying here is not only relevant to installer
problems. Downloading several hundreds of megs of updates on every
fresh install can get very tiresome, time consuming and costly.

Using the updated isos I save about 20-40min on each install here,
multiply that with the ~50 machines running them. I think I saved
some time here, and time is often important.

> There is absolutely no garuntee that respins produced ANYWHERE by
> ANYONE will not introduce a DIFFERENT set of problems for a different
> set of hardware.  Telling everyone to go out and grab a fc4.2 which
> uses a different installer codebase and an different installer
> kernel..

Alternatives is good. This is what the whole linux thing is about.

One wouldn't have to mirror all releases of course. Say the original
FC4 and the latest respin. One of those should work for most people.
The fedora download page should also make it clear that FC4 is the
best tested one, but the FC4.* has fixed some bugs and contain newer
packages BUT may contain new bugs.

> is asking for a whole different set of bugs... bugs that have
> recieved far less testing in terms of hardware coverage than the
> original installer did.  Just because its a newer version doesn't mean
> there will not be regressions for some hardware.. as we see with
> update kernels... we will see it with update installer isos as well.

Since anaconda is not updated at all in FC4, I'd say fixing the few
bugs there would be pretty unlikely to make new ones.

The alternative of saying "wait 6 months, then try our new version" or
"you need to use the aging FC3" is not a good solution either.

What about us few who have hardware not yet supported by the original
FC4 kernel? Sorry, paperweight.
I have installed on several servers here that do not work with the
original FC4 kernel due to things like sata/scsi controller too new.

> Its time to face facts... no release of the installer is going to be
> perfect... nor can the release team test all potential hardware
> combinations.

Agreed.

Most package updates don't break installs, yes you can do something
wrong in the spec file for the rpm.

A few can, such as kernel and anaconda.
Isn't it worth it to pursue these?

After all, kernel bugs should appear as much in a pre installed
as in a new install. And in any case should be fixed one way or
another.

Anaconda bugs should be pretty simple fixes since it probably
wouldn't need new features / bells & whistles.

> Update isos are not a silver bullet, especially in an
> aggressive development model where the kernel itself could see
> hardware-specific regressions with every update.  Can you be so very
> sure that a respin which includes an updated kernel will install
> without issue on my systems, when the original installer had no
> problem at all?

Updated isos are nowhere near a perfect solution.

But I'd say they are helping.

> Don't get me wrong, I'm all for seeing respins produced in a more
> formalized way, for a vareity of reasons, by people who are willing to
> do the work to maintain them and to run point for bug reports that are
> specific to the respins which are not part of the original installer.

Good. But a little cooperation would be nice.

> But do not make the mistake of overselling the respins as a solution
> for all the community's ills. Each re-spin will have its own unique
> problems and regressions which will need manpower to track in
> bugzilla.

Indeed.

> Demanding that the fedora core release team build and
> maintain respins without understanding the amount of effort it would
> take for them to competently track bugs across the different isosets
> is unjustified.

I'd be glad to help out with that, but I would certainly appreciate
help from the official team when I get stuck with a problem I cannot
solve myself.

> Sadly, the community so far who have stepped up to
> produce respins have not been communicating  with Fedora
> representatives, who have made an effort to start a dialog on how to
> formalize the effort.

The one mail I received from Rahul did not strike me as a
"I'll help you" mail, but rather a general suggestion.
The other one we have found out never reached me.

It was never the lack of willingness.

> The work on respins doesn't stop when the respin
> is built and the torrent file is made public... issues with the
> respins must be tracked and that will require an additional time 
> commitment.

I have gotten a few bugreports about FC4.1 but none about FC4.2.
Excepting of course the installer-boot-menu-needs-garbage and
swap-label-contains-garbage bugs. Both of witch could have been
fixed had there been official updated rpms.