[1346] in athena10
Re: Apt repository layout
daemon@ATHENA.MIT.EDU (Tim Abbott)
Fri Mar 6 20:47:59 2009
Date: Fri, 6 Mar 2009 20:42:06 -0500 (EST)
From: Tim Abbott <tabbott@MIT.EDU>
To: Evan Broder <broder@mit.edu>
cc: debathena@mit.edu
In-Reply-To: <49B1C016.2090206@mit.edu>
Message-ID: <alpine.DEB.2.00.0903062021070.15811@vinegar-pot.mit.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
As I've said before, I agree with the general plan of adding testing
releases. More comments below.
-Tim Abbott
On Fri, 6 Mar 2009, Evan Broder wrote:
> Assuming I can manage to wrap my head around the necessary Makefiles,
> I'm hoping to create the separate releases this weekend, and maybe write
> some shell scripts to make migrating packages between releases a little
> easier.
We'll probably also want to update <http://debathena.mit.edu/package-list>
or something similar to display the state of -proposed.
> Once the releases exist, there's some dev work to be done to take full
> advantage of them:
>
> - debathena-auto-update should add or remove the -proposed release
> based on clusterinfo.
While we're updating this, we should probably remove the current
clusterinfo controls on debathena-auto-update that choose between
debathena.mit.edu and athena10.mit.edu, since presumably those will be
unnecessary (or more likely, modify the code for this new purpose...).
> - The autodebathenificator should upload packages to -proposed (and
> then we can finally turn it on!)
Sounds good.
> - We should have a cron job to notify us every so often that something
> has been sitting in -proposed for more than a day or two, because that
> may mean somebody forgot to migrate it to production
One or two days isn't a great testing period unless we actually make sure
there are machines running -standard and -workstation (or whatever they
change to) with -proposed installed that actually take the update during
that interval. So I guess I'm saying that we'll want to make sure
developers actually upgrade when things go out to -proposed.
> I'm a bit on the fence in terms of how to use the new layout once we
> have it in place, though. I do think that at some point we should shift
> our policy some in terms of when we ship updates. Currently updates
> undergo anywhere from no testing to minimal testing to extensive testing
> depending on the update and the developer. Sometimes they're tested on
> multiple platforms, sometimes just the developer's.
>
> On the one hand, I think that requiring all updates to go through
> -proposed can lead to a more stable release. Previously, I had planned
> to suggest that we let any non-emergency updates sit in -proposed for at
> least 24 hours before going into production.
>
> However, Debathena is only moderately ready for the cluster right now. I
> think one of the most important things we can do to keep people from
> perceiving Cluster Debathena as not being ready is responding to user
> issues as quickly as we can, and requiring that packages sit for 24
> hours is not a good way to create an image of being highly reactive.
>
> So I think that, for now, we should leave this up to developer
> discretion, but in the case of non-user-requested and non-emergency
> updates, we should consider passing them through -proposed for a while
> to give a wider variety of users a chance to test the changes.
Yeah, I suspect that this kind of policy would be counterproductive until
things have stabilized more.
-Tim Abbott
