[1361] in athena10
Re: Apt repository layout
daemon@ATHENA.MIT.EDU (William Cattey)
Sat Mar 7 14:49:51 2009
In-Reply-To: <200903071935.n27JZMF4005398@byte-me.mit.edu>
Mime-Version: 1.0 (Apple Message framework v753.1)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <FB657F47-DD7A-47E3-A6A6-E14DD4CBB703@mit.edu>
Cc: Evan Broder <broder@mit.edu>, Jonathan Reed <jdreed@mit.edu>,
debathena@mit.edu, Greg Price <price@mit.edu>, Tim Abbott <tabbott@mit.edu>
Content-Transfer-Encoding: 7bit
From: William Cattey <wdc@MIT.EDU>
Date: Sat, 7 Mar 2009 14:43:38 -0500
To: Mitchell E Berger <mitchb@mit.edu>
The release testing cycle was published at:
http://web.mit.edu/ist/topics/athena/testing-cycle.html
Mitch does a very good job of remembering the phases.
-Bill
On Mar 7, 2009, at 2:35 PM, Mitchell E Berger wrote:
> So, it's been a while, but my recollection of the old Athena release
> cycle was that there were generally 5 phases of a major release:
>
> o Crash-and-burn, when it really wasn't ready for anyone but core
> developers to muck with, and involved the expectation that you were
> going to have to regularly blow away your machines; no real
> expectation
> that the installer worked or that upgrades wouldn't ruin everything.
> The z in version x.y.z was 0 the whole time.
>
> o Alpha, much as described already. Developers used it, but not ready
> for other people to see. Used the dev cell.
>
> o Beta, pretty much as described. Note that even machines in the beta
> cluster that were AUTOUPDATE=TRUE did not take the beta release
> without
> manual intervention. At this point, the installer might work, but
> it might not quite exist, though update_ws should work from the
> previous
> version. Beta was believed to be safe from destroying machines.
>
> o Early, which represents basically what you guys just did to 10% of
> the clusters. It was the preview release, at which point it was
> believed
> to be ready for general consumption for feedback, but some tweaks
> might
> still be made. There's early cluster info and machine mappings in
> moira, and this was the first point at which machines set
> AUTOUPDATE=TRUE
> would take a new release on their own.
>
> o Public, which is pretty obvious what it means.
>
> I don't know if there was actually a moira cluster for crash-and-burn.
> It likely wouldn't do a whole lot... if you couldn't roll your own
> cluster info, you definitely couldn't handle a machine running the
> release at that point. But there are moira clusters for the rest of
> them, and it sounds like early was lost from Jon's description.
> People in the early cluster definitely would want to be running
> -proposed all the time. People in the alpha cluster would presumably
> want to be running -dev all the time. Which one people in the beta
> cluster would want, I'm not sure of. Probably -proposed also.
>
> As for bleeding, I believe that was a special one-time-only thing
> for 8.4 when I/S's very first supported Linux release was coming out.
>
> Mitch
>
>> Jonathan Reed wrote:
>>>
>>> On Mar 7, 2009, at 1:51 PM, Jonathan Reed wrote:
>>>
>>>> Basically, machines in the "alpha" cluster get a bleeding release
>>>> when we do a major version update.
>>>
>>> Hrm, actually "bleeding" is something else, and I think was
>>> linux-only, but the rest of what I said is mostly correct, I think.
>>> I think "alpha" was more likely to work than "bleeding", but was not
>>> yet "beta" quality.
>>
>> Yeah, I think that my idea for "-dev" is closer to the "bleeding"
>> cluster of Athena 9
>>
>> - Evan
