[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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