[6236] in Release_7.7_team
Re: publicity
daemon@ATHENA.MIT.EDU (Jonathan Reed)
Thu Feb 26 23:44:13 2009
Cc: Evan Broder <broder@mit.edu>, William Cattey <wdc@mit.edu>,
release-team@mit.edu, debathena-dev@mit.edu
Message-Id: <46E6EB35-FDDA-4486-B8C1-C3AB215D4270@mit.edu>
From: Jonathan Reed <jdreed@MIT.EDU>
To: Tim Abbott <tabbott@mit.edu>
In-Reply-To: <alpine.DEB.2.00.0902261950230.11801@vinegar-pot.mit.edu>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v919.2)
Date: Thu, 26 Feb 2009 23:43:38 -0500
X-Spam-Flag: NO
X-Spam-Score: 0.00
> (1) a merged installer is committed and deployed on debathena.mit.edu
It looks like the major differences are:
1) The Debathena installer asks you guided questions to figure out
whether you want standard, login, or workstation, whereas the Athena
10 installer makes you pick one by name
2) The Debathena installer will install module-assistant and build
openafs for you if it's not available for your kernel
3) The Athena 10 installer can deal with unattended cluster installs,
and asks about thirdparty and stuff.
Obviously #3 needs to happen.
For #1, I would say that the script should present the available
options, and make you pick one by name. At the bottom, it can say
something like "For more information on selecting the installation
option that best suits you, see http://debathena.mit.edu/beta/installation-options
" (I'll keep that URL the same).
For #2, I have no objection to it building openafs if modules aren't
available, assuming there are no major problems with this. If the
build fails for some reason, it should explicitly tell the user that
something really bad happened and they should probably e-mail
debathena@ before trying to use their machine.
-Jon
