[6542] in Release_7.7_team
Re: Collaboration document update
daemon@ATHENA.MIT.EDU (Evan Broder)
Thu Dec 3 15:53:27 2009
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.1.10.0912031531030.27499@dr-wily.mit.edu>
Date: Thu, 3 Dec 2009 15:53:18 -0500
Message-ID: <2706d8dd0912031253l67215d52xa70b7b84d4da8d5c@mail.gmail.com>
From: Evan Broder <broder@MIT.EDU>
To: Geoffrey Thomas <geofft@mit.edu>
Cc: release-team@mit.edu, debathena-dev@mit.edu
Content-Type: text/plain; charset=ISO-8859-1
X-Spam-Flag: NO
X-Spam-Score: 0.00
On Thu, Dec 3, 2009 at 3:42 PM, Geoffrey Thomas <geofft@mit.edu> wrote:
> On Thu, 3 Dec 2009, Evan Broder wrote:
>
>> So does anybody have ideas for how we can allow for urgent updates
>> without sacrificing quality control?
>
> I think one thing that would help is reintroducing something akin to
> early-linux with a scope at least as big as the Debathena Beta deployment,
> so we can tell users "Can you go try it on one of these machines and see if
> your bug is fixed".
Sure - I've been mumbling a while about wanting to move early-linux
back into proposed, instead of production. I'll send a separate e-mail
about that as soon as I finish this one so we can move that forward.
> We could either do this with another apt repository or via machines that
> take updates less frequently (some way to remotely inhibit or force updates
> on a certain machine would be kind of cool -- if we did that we could even
> say "We've pushed an update to your machine, can you log out, wait for the
> update to apply, and log back in").
I suspect that forcing updates to a given machine would be seen as
moderately dangerous if it was allowed to run unauthenticated (I'd
certainly be skeptical of it), and we can't authenticate to cluster
machines.
Hmm...what if the cluster machines ran a Moira update_server that we
could authenticate to...?
- Evan
