Secure testing team - Mar 2006 - (forw) Re: secure-testing details

So, today everyone has his fingers a bit too fast :)

correct address now.


Cheers,
Andi
----- Forwarded message from Andreas Barth <aba@not.so.argh.org> -----

From: Andreas Barth <aba@not.so.argh.org>
To: Joey Hess <joey@kitenet.net>
Cc: zobel@ftbfs.de, secure-testing@lists.alioth.debian.org
Subject: Re: secure-testing details
Date: Fri, 26 Aug 2005 16:12:18 +0200
Message-ID: <20050826141218.GZ2526@mails.so.argh.org>
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.5.9i

* Joey Hess (joey@kitenet.net) [050826 15:42]:
> (Bringing secure-testing list into the loop. Note that "the
package" is
> an upload I made of kismet. I''ve just checked in an update to the
website
> that explains how to make uploads.)
[redirecting to the right list]

> Andreas Barth wrote:
> > * Andreas Barth (aba@not.so.argh.org) [050824 23:22]:
> > > - wanna-build integration
> > > - installation without handholding the scripts :)
> > > - rsync/http-access to the pool
> > 
> > all done. The package is now autobuilt for most archs, and more archs
> > are still yet to come - but there shouldn''t be any
> > infrastructure-related issue any more.
> > 
> > So, some more question from me:
> > - Who should be notified on uploads? The real debian maintainer, or
only
> >   the "NMU"er? Is there a global changeslist? Should there
be a Bcc-list
> >   (i.e. all uploads including binary-only ones go there)?
> 
> However this works for security.d.o seems ok to me. OTOH, we might want
> to dump all upload messages in a list of the team, we could add a new
> list such as secure-testing-changes for that purpose.
Well, security.d.o doesn''t send messages out by itself, because all is
uploaded to ftp-master, and ftp-master sends out. Usually, the
source-uploads are mailed to a -changes-list, and the Bccs go only to
PTS. I think we can forget about the Bccs for now, and if we need them
later, we can still add them.
> > - we need to proceed somehow with the "migration" of
packages from
> >   etch-proposed-updates to etch. So, where should we discuss about
that?
 
> So, the model I have been using is that we should only upload a fix that
> has also been uploaded to unstable. This allows some testing of the
> upload before we force it into (secure-)testing, avoids us making
> uploads for things that will reach testing in the usual way without
> undue delay, and it ensures that there will be a working upgrade path
> from the security fix to any new versions that are released into
> unstable, and also ensures that the fix will eventually propigate to
> testing (from unstable).
Well, _that_ part of the process doesn''t have any effect on katie.

As just discussed on IRC, we''ll need some "approval
mechanismn" that
pushes a package from etch-proposed-updates to etch. Probably something
with a hints-file etc. :)

> I think this is ok, as long as we have a manual approval process before
> it hits the public repo that the team will be telling users to use if
> they want testing security updates.
Well, the first repro is also public, but I wouldn''t recommend people
using it - unless they want to snoop what currently happens :)

> > - where should the website/documentation go to?
 
> We have a website directory in our svn, any docs can go there. As
> mentioned above I''ve included some already. If you have dynamic
stuff,
> it can go on the secure-testing-master host.
Well, there''s not so much dynamic - except of the packages of course.
They are on
deb http://secure-testing.debian.net/debian-security-updates
etch-proposed-updates/security-updates main contrib non-free
deb http://secure-testing.debian.net/debian-security-updates
etch/security-updates main contrib non-free

> > - mirror policy? Do we accept mirrors, and what do we require from
them?
> >   I tend to say that we only accept push mirrors, keep them under
strict
> >   nagios control and require the mirrors in well-connected countries
> >   (i.e. Europe, North America) to have their files stored in
> >   /debian-security-updates (so that the URLs are similar).
> 
> I think it''s too early to worry about mirrors.
My experience with volatile is that mirrors come quite fast. :)



Cheers,
Andi

----- End forwarded message -----