[3092] in SIPB_Linux_Development
Re: SIPB Installer Bugs: Custom Install
daemon@ATHENA.MIT.EDU (Alex Coventry)
Thu Oct 12 10:23:21 2000
Date: Thu, 12 Oct 2000 10:23:15 -0400
Message-Id: <200010121423.KAA19759@pickled-herring.mit.edu>
From: Alex Coventry <alex_c@MIT.EDU>
To: warlord@MIT.EDU
CC: linux-dev@MIT.EDU, cfox@MIT.EDU
In-reply-to: <sjmy9zuxih1.fsf@rcn.ihtfp.org> (message from Derek Atkins on 12
Oct 2000 10:05:46 -0400)
[Camilla]
> Given how owls has pledged I/S support for machines installed with our
> installer, it seems poor to let it make non-supportable configurations
> easy to do.
[Derek]
> SIPB does not report to owls, and we should not let owls constrain our
> projects based on their decisions. If owls wants a specific product,
> then they should get the I/S funding to create that specific product;
> they should not depend or require SIPB to create that specific product
> for them.
As I understand it, they're not constraining us, they're doing us a
favour. This isn't shrink-wrapped software that you can ship and forget
about; people are going to be ringing us up wanting to explain the
gremlins that have started flying out of their monitors since they used
our install, and if we can't help them, the installer is unlikely to
have much impact beyond disgruntling the first dozen users this happens
to. So if someone is generous enough to do the explaining for us, that
could save us a huge amount of time, and deserves a little reciprocity.
Sam and I spent 45 min on the phone with a beta tester yesterday because
the RedHat installer decided he had a multi-processor machine (though he
didn't) and installed the corresponding kernel, which is incompatible
with the AFS packages. Had we officially shipped, saving that 45 min
alone would have been worth dumbing down the installer a little, in my
opinion.
Alex.
