[6234] in Release_7.7_team

home help back first fref pref prev next nref lref last post

Re: publicity

daemon@ATHENA.MIT.EDU (Jonathan D Reed)
Thu Feb 26 19:49:39 2009

Date: Thu, 26 Feb 2009 19:48:56 -0500 (EST)
From: Jonathan D Reed <jdreed@MIT.EDU>
To: Evan Broder <broder@MIT.EDU>
cc: William Cattey <wdc@MIT.EDU>, release-team@MIT.EDU
In-Reply-To: <49A72E01.50502@mit.edu>
Message-ID: <Pine.LNX.4.64L.0902261941520.30792@infinite-loop.mit.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Flag: NO
X-Spam-Score: 0.00



On Thu, 26 Feb 2009, Evan Broder wrote:

> I like debathena.mit.edu/beta/ - I know it was created to preview what a
> merged website looks like, but calling this "Debathena Beta" seems more
> or less appropriate.
>

That was my thinking, but I wasn't sure if there would be any objections 
to calling it "Debathena Beta".

This idea has the following advantages:
- The debathena website can be an evolving concept, and trivially replace 
debathena.mit.edu when we're ready.
- The URL matches the naming scheme.
- We don't have to migrate content formats twice.

There are a couple of cons, as I see it:
- It requires merging the installers (we should have one installer page). 
This means that debathena-workstation and lower should have the same 
packages across both repos.  (ie: if I install debathena-workstation from 
the debathena repo, I should get exactly what I get from the athena10 
repo).   I think this is mostly true, right?  We would have to merge the 
greeters, I guess.  I don't care if cluster machines stick with the 
athena10 repo for now, but since we're planning on merging, we should 
minimize the number of machines that we don't control which are using the 
athena10 repo.
- Hrm, I guess that's only one con.

Thoughts?

-Jon



home help back first fref pref prev next nref lref last post