Re: about volatile.d.o/n
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
Reply to: