Will Lowe <[EMAIL PROTECTED]> 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
