RFD: Draft for a volatile.d.o policy (was: Re: Updating scanners and filters in Debian stable (3.1) )
Thomas Bushnell BSG [u] wrote on 08/10/2004 18:18:
Will Lowe <harpo@thebackrow.net> writes:
My argument is just that even if you backport the important features
of a new release into an old codebase, it's hard to make any valuable
claims about the resulting product if the "backport" changes more than
a few lines of code.
This is true if you don't know what you just did. If you know what
you did, you may well be able to make a claim like "no new command
line features are added".
Doing a backport of some upstream change is usually a pretty difficult
task (except for smaller security fixes). It's pretty easy to claim "no
new command line feature added", but it is pretty difficult to claim "no
new bugs added" or "all necessary security fixes added".
I agree that a pure security fix (like s.d.o security updates) should
not introduce new code functionality, but only fix the security bug. At
times, this might be a hard task, but usually it is an easy to medium
level (though usually also very time consuming) task.
However, what we are talking about here are packages that become less
and less useful over time, these are namely:
1) anti-spam software
2) security scanners (snort and the like)
3) virus scanners (clamav etc.)
And since they are pretty closely bound to the above:
4) mail-scanners (amavisd etc.)
These are packages that become less useful over time, not because
upstream releases new versions with new features, but because the old
features aren't enough to fulfill the original tasks anymore.
Therefore, and because you asked for a policy for v.d.o before (more or
less directly), here is a new try for such a policy (sorry for sending
the original one directly to you, Thomas, instead of the list):
======================================================================
Draft for a volatile.debian.org packaging and update policy.
Target:
volatile.debian.org (or short: v.d.o) is intended to be a repository for
packages which degrade over time with respect to their usefulness. These
include, but might not be limited to:
1) Virus scanners (clamav etc.)
2) Intrusion detection systems and security scanners (snort, nessus,
etc.)
3) Anti-Spam software (spamassassin etc.)
4) Tools which are so closely related to a software in 1-3 that they
might need to be updated when a new version of the related software
is introduced to v.d.o
Policy for v.d.o
- Packages in v.d.o are generaly limited to the kind of software listed
above.
- v.d.o is devided into two parts:
- volatile.debian.org
- volatile-testing.debian.org (short v-t.d.o).
- A new (version of a) package always enters v-t.d.o first, direct
uploads to v.d.o are strictly forbidden.
- Before a package enters v.d.o, it must prove it's stability by living
in v-t.d.o for 2 weeks first without a qualified bug report against
it. A qualified bug report is hereby defined as a report for a new bug
in the version uploaded to v-t.d.o which doesn't exist in the version
in v.d.o. If there is no corresponding version in v.d.o, it must live
in v-t.d.o for 6 weeks without any critical bug being reported against
it. No package may enter v.d.o with RC bugs open.
- A new version uploaded to v.d.o should restrict itself to new code
which is needed to keep fulfilling the original task of the package
when it first entered v.d.o.
- A new upstream version which doesn't adhere to the previous rule may
enter v.d.o under a new name. Alternatively, it may enter v.d.o if
it is certain that it doesn't break compatibility with any package
using it either in the main stable release of Debian or v.d.o
- If a new upstream version breaks compatibility with existing packages,
it may only enter v.d.o if it lived in v-t.d.o for at least 6 weeks
and all packages where compatibility has been broken are
simultaneously entering v.d.o (or entered it before).
- If a new version of a Software (A) introduced to v.d.o requires new
versions of software (X) which are not yet part of v.d.o, these new
versions might only be introduced to v.d.o if that new version of X
does not break compatibility with the current Debian stable version
and is introduced to v.d.o simultaneously with the new version of A.
- Only DFSG-free software may enter v-t.d.o or v.d.o!
- Software in section 4 of the "targets" paragraph may only be updated
in v.d.o if this is needed to either keep support working for a newer
version of a software in v.d.o or if this introduces support for a
new software in v.d.o (for example if bogofilter support is added
to amavisd). Other new features are no reason to update such a
package.
======================================================================
Like said before, this is a very basic and preliminary version of a
v.d.o policy, but it should make the most important things quite clear.
I know this policy is not really to the taste of Thomas Bushnell,
especially because new features _might_ be introduced. But with the
pretty small selection of software allowed to enter v.d.o and given the
fact that the upstream sources of those packages often change so quickly
that is more than likely for the maintainer to introduce a new bug in
the backport of an update, while the new upstream source is generally
regarded as stable for production use, it might be preferable to just
update to the new upstream version instead of keeping the old version
plus various backported changes which might have introduced new bugs.
regards,
Sven
Reply to: