I'll add a few my consideration already discussed in IRC with Andi and others. Feel free to fill the gaps :)
On Fri, Oct 08, 2004 at 05:51:48PM +0200, Andreas Barth wrote: > 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; > So no new styles of packaging: no dpatch introduction from scratch, for instance. > - Good candidates are clamav (including spin-offs), spamassassin, > chkrootkit; > I'd add IDS like snort. > - 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; > In some context volatile would be not useful, so separating the two things is definitively The Good Thing To Do. > - for bugs, the normal debian bug tracking system should be used. > ... adding a volatile tag probably as for experimental? But if nothing would be broken by volatile pkgs, probably BTS is superfluous ;-) > > 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. > Unfortunately I think so too. > - "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. > Indeed, I think we could have a few time post sarge release to buildup the thing. -- Francesco P. Lovergine
