about volatile.d.o/n

[Andreas Barth <aba@not.so.argh.org>]

Hi all,

we had some discussion about volatile, and I'm more and more considering to
pick this task up. I think some issues are quite obvious:

- packages should only go in in cooperation with the maintainers;

- volatile is not "just another place" for backports, but should only
  contain changes to stable programs that are necessary to keep them
  functional;

- Good candidates are clamav (including spin-offs), spamassassin,
  chkrootkit;

- It should allow any administrator to "just use" volatile, as they "just
  use" security.d.o, and they should be confident that nothing is broken by
  that;

- for bugs, the normal debian bug tracking system should be used.


Some things are not so obvious:

- security support: There should be security support for volatile. However,
  security.d.o is probably not the right place for that, and adding another
  task to the security-team is IMHO also not the way to go. So, this needs
  to be placed on the burden of the volatile team.

- "releases" of volatile: One could consider to seperate volatile into a
  release and a staging area. An advantage would be that system
  administrators would only need to update on some times. However, if we
  restrict volatile, only upload required changes and don't have more than
  10 packages in it, we don't need that.

- adding volatile packages to point releases: Though it may be seen as good
  idea to add volatile packages at the next point release, this is
  currently a no-go. I can see the good reasons for that, and I accept
  them.


Two technical questions remain open for now, and needs to be solved
independend of the policy questions above.

- ftp-server: Should volatile be a "normal" part of the debian ftp-server,
  or be setup independently (like e.g. security.d.o is)? Normal part would
  of course be nicer for our users (and especially mirroring is free), but
  requires some more work initially. However, this decision is in the
  domain of the ftp-masters.

- architectures/buildd support (partly connected with ftp-server): Which
  architectures should be supported? Perhaps starting with a smaller number
  is a good idea, and adding more if they can cope with the updates.


I added http://volatile.debian.net/ to be a placeholder for the current
discussions.

Also, there is a archive present on
http://volatile.debian.net/debian-volatile, so if maintainers want to start
adding packages, they may contact me.

That's all for now. Comments and suggestions are welcome.


Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C