On 1/22/06, Les Mikesell <lesmikesell@xxxxxxxxx> 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
