[Secure-testing-team] Re: secure-testing details

[Joey Hess]

(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.)

(Sent to the right list this time, d'oh.)

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.

> - Do you want to get katies "dinstall results"-mails? and the katie crontab
>   results? do you want to receive mails to ftpmaster at secure-testing.d.n?
>   (currently, all "dinstall results"-mails go to ftpmaster, and I want
>   to keep that - of course, adding an extra address shouldn't be an
>   issue)

Not especially interested in those mails. :-)

> - 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).

> - currently, anybody in the debian keyring can uploads, as well as fs
>   (he runs the amd64-buildd). If you want changes, please say so.

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.

> - 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.

> - 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.

> And last not least, we should probably write some user documentation and
> make an announcement.

Once we have some packages to announce in a usable public repo, yes.

-- 
see shy jo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20050826/55c3c2a1/attachment.pgp