On 9/7/05, Jeff Spaleta <jspaleta(a)gmail.com> wrote:
On 9/7/05, Paul A Houle <ph18(a)cornell.edu> wrote:
> I don't really know how bad the problems are. Most of the codepath
> involved in the install is going to be on the CD and not on the rpms.
> Most of the rpms are getting 'tested' by people who are running
> up2date.
anaconda has "magic"..voodoo magic. Perhaps its best not to assume
that up2date and anaconda treat depresolution equally.
The main questions I see are
>
> (i) will something about the rpms cause the installer to malfunction?
> (ii) will something go wrong during firstboot... this is the one code
> path that isn't getting tested daily by Fedora users.
>
> Careful software engineering can minimize the codepath affected by
> (i) and (ii) problems and reduce the chance of problems.
careful software engineering certaintly sounds like manpower to me.
Who exactly is going to be watching out for this? Someone is going to
actually have to do the testing and catch problems. Especially if the
goal is to respin to fix install time problems. Anytime you go into
the code to fix something you can break something...regardless of how
"careful" your software engineering is. If there isn't the manpower to
do the testing after a change in made.. you end up with a situation
where people having problems unique to a respin. Its hard enough
helping people through well understood cornercase installer problems
with the release isos 2 months after a release. You start throwing
monthly isos out there without serious regression testing and you get
into deeply uncomparable situations. I'm certaintly not going to stick
my neck out and attempt to help people with a respin that I havent
used. And I'm certaintly not going to be doing weekly or monthly
respin based installs on top of tracking rawhide I don't have the
hardware to keep up with that.
> A less ambitious goal is to keep the installer the same and change
> the rpm's. This won't solve everybody's problems, but it will make
> Fedora installs faster around my house.
Sometimes I find it better to choose reliably broken with known
workarounds..than unreliably new. I'm more than willing to get on the
bandwagon once someone shows me with that scripted respins of the
distro like this don't need aggressive pre-release testing by putting
these things out and the wild and collecting usage information and
bugreports. I'm not inclined to ask developers to take on
unreasonable maintainership burden to keep respins sane and I'm not
inclined to throwing respins over the wall and causing a bigger mess.
-jef"dragsters are fast.. lets all drive dragsters to work"spaleta