[1360] in athena10
Re: Apt repository layout
daemon@ATHENA.MIT.EDU (Mitchell E Berger)
Sat Mar 7 14:41:38 2009
Message-Id: <200903071935.n27JZMF4005398@byte-me.mit.edu>
To: Evan Broder <broder@MIT.EDU>
cc: Jonathan Reed <jdreed@MIT.EDU>, debathena@MIT.EDU,
Greg Price <price@MIT.EDU>, Tim Abbott <tabbott@MIT.EDU>
In-Reply-To: Your message of "Sat, 07 Mar 2009 14:08:51 EST."
<49B2C643.7000000@mit.edu>
Date: Sat, 07 Mar 2009 14:35:22 -0500
From: Mitchell E Berger <mitchb@MIT.EDU>
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
