[Secure-testing-team] (forw) Re: secure-testing details

[Andreas Barth]

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

correct address now.


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

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

* Joey Hess (joey at 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 at 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 -----