(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.)
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.
> - Do you want to get katies "dinstall results"-mails? and the
katie crontab
> results? do you want to receive mails to ftpmaster@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-commits/attachments/20050826/2b052899/attachment.pgp