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

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.


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


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.


Reply to: