[1349] in athena10
Re: Apt repository layout
daemon@ATHENA.MIT.EDU (Evan Broder)
Fri Mar 6 21:06:15 2009
Message-ID: <49B1D528.5040008@mit.edu>
Date: Fri, 06 Mar 2009 21:00:08 -0500
From: Evan Broder <broder@MIT.EDU>
MIME-Version: 1.0
To: Tim Abbott <tabbott@mit.edu>
CC: debathena@mit.edu
In-Reply-To: <alpine.DEB.2.00.0903062021070.15811@vinegar-pot.mit.edu>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Tim Abbott wrote:
>> 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...).
>
Yeah, I had been planning to roughly repurpose that code for this.
>> - 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 can certainly promise that I'll have multiple Hardy machines running
-standard for the near future, and I have apticron running on all of
them, so they get updated within a day of the updates being available.
-workstation machines shouldn't be a problem, because I suspect that
many of them will be running -auto-update as well, so they should get
updates when they show up in -proposed.
- Evan
