Fedora Core 3 Transferred to Fedora Legacy

[Jeff Spaleta]

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?

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.. 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.
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.  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?

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. 
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.  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.  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 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.

>
> > Would you also count the work going on with Kadischi as being an RHEL
> > inspired subproject?
> > http://fedoraproject.org/wiki/Kadischi
> > I wouldn't.
>
> It looks like a badly-need catch up to all the other popular
> distributions to me.

What is your point?  I notice you didn't deny that this project was a
response to "community interest".
If you want to see it catch-up faster.. then get invovled.
If you want to see it fail so that you can continue to complain about
how Fedora doesn't have a livecd.. then don't get invovled.  Either
way the fate of this piece Fedora technology is primarily in the hands
of community contributiors and not a RHEL directive.  Whether or not
prefer to be an active supporter of those community contributors or
whether you'd prefer to sit on the sidelines and say their
contributions aren't valued because they are playing catch-up is up to
you.

-jef