[1015] in athena10
Re: Beta repo layout
daemon@ATHENA.MIT.EDU (Tim Abbott)
Wed Jan 28 15:53:39 2009
Date: Wed, 28 Jan 2009 15:52:40 -0500 (EST)
From: Tim Abbott <tabbott@MIT.EDU>
To: Evan Broder <broder@mit.edu>
cc: debathena@mit.edu
In-Reply-To: <497CA403.6000005@mit.edu>
Message-ID: <alpine.DEB.2.00.0901281544200.12838@vinegar-pot.mit.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
I think a protocol that involves packages living in a beta repository for
a few days before moving to production would be desireable, especially if
there were several frequently-used machines (e.g. SIPB office heads) that
lived on the beta repository and were running our auto-update tool.
The primary reason why a separate beta repository might be better than
multiple components within a single repository is that it allows one to
use different privilege requirements for the two different repositories.
-Tim Abbott
On Sun, 25 Jan 2009, Evan Broder wrote:
> I'd like to switch from having a completely separate apt-beta repo to
> having a single apt repo with {etch,lenny,dapper,etc}-beta releases.
>
> Since the terminology is a little unclear on this sort of thing, I'll
> re-express my desires in terms of changes to sources.list :)
> Old:
> deb http://debathena.mit.edu/apt-beta hardy debathena debathena-config
> deb-src http://debathena.mit.edu/apt-beta hardy debathena
> debathena-config
>
> New:
> deb http://debathena.mit.edu/apt hardy-beta debathena debathena-config
> deb-src http://debathena.mit.edu/apt hardy-beta debathena
> debathena-config
>
> This will make it substantially easier to move packages from beta to
> production, which I think is important.
>
> Once we do that, I think it wouldn't hurt to have a standing policy of
> letting any non-emergency updates sit in beta for a day or so before
> going live.
>
> Anders, Tim - do you guys have any thoughts on this? Any reason it
> wasn't done this way initially?
>
> - Evan
