The debian-volatile Project

debian-volatile for developers

What is debian-volatile?
Some packages aim at fast moving targets, such as spam filtering and virus scanning, and even when using updated data patterns, they do not really work for the full time of a stable release. The main goal of volatile is allowing system administrators to update their systems in a nice, consistent way, without getting the drawbacks of using unstable, even without getting the drawbacks for the selected packages. Instructions for using the volatile archive can be found at the debian-volatile users page.

Acceptance rules
In order to include a package into debian-volatile, it has to meet the following criteria:

The package should only be prepared in cooperation with its maintainer(s).
In other words: a package should be uploaded to debian-volatile only by its own package maintainer(s). This is the only way we can ensure security support for packages in debian-volatile as well as proper packaging and a smooth upgrade path.
debian-volatile is not "just another place" for backports, but should only contain changes to stable programs that are necessary to keep them functional. A special section of the archive, named sloppy, can be considered to include packages with a bit more relaxed constraints, in respect with the main regular debian-volatile archive. That needs to be discussed on the list.
The package should allow any administrator to "just use" volatile, as they "just use" security.d.o, and they can be confident that nothing could be broken by that.
The usual Debian bug tracking system should be used for bugs.
Packages in debian-volatile cannot require any package outside of stable main (or any later version of it) to run or build. Packages need to be auto-buildable within the same (stable) release. This constraint could be relaxed for the sloppy archive, on case by case basis. That needs to be discussed on the list.
Packages need to be conformant to stable policy; we currently take http://release.debian.org/etch_rc_policy.txt as a hint about what is ok and what not.
The upgrade path from volatile to the next stable release needs to be at least as easy as for the stable release; version numbers in volatile must not be higher than those in testing, for instance.

Procedure to include a package
We experienced that the procedure below works quite well for new packages inclusion in debian-volatile:

Send an e-mail to the mailing list debian-volatile@lists.debian.org
This is for discussing your changes in public. It is also a good idea to include a link to a unified diff. Please, respect the debian-volatile guidelines, i.e. apply necessary changes only.
Fellow developers are encouraged to join this discussions, so that the debian-volatile team would know what changes the users like, and what not. Everybody on the list is encouraged to review the proposed changes.
Upload to debian-volatile
After receiving consensus from the list, please upload at least source and binary-all packages to volatile-master.debian.org (see below) using FTP. Please document changes in debian/changelog. Just writing
* Upload package to volatile
is NOT acceptable. If you already did an upload to volatile for the package, and your proposed changes to the previous version are security fixes, please tell us in advance. If you already have got one or more CVE identifiers, please put them in the changelog for tracking the security issues. If you do not have any CVE id, please tell us anyway, because we can obtain them for you. If you want to contact the debian-volatile team in private, please contact one of its members. Sometimes there are embargo dates on publication of security bugs and their fixes. We respect them.
Packages are built automatically
Packages are built by the autobuilder network. No interaction or manual processing is needed for that.
A Volatile Update Announce is being prepared
While the package is autobuilt, the debian-volatile team will contact you about the content of the announcement mail, which will be sent via debian-volatile-announce@lists.debian.org
Package is released.
The package is finally reviewed and released.

How to upload to volatile
You should add the following sniplet to your ~/.dput.cf:

[volatile]
method = ftp
fqdn = volatile-master.debian.org
incoming = /pub/UploadQueue/
login = anonymous
hash = md5

If you are using dupload, the stanza below should be added to your ~/.dupload.conf:

$cfg{'volatile'} = {
        fqdn => "volatile-master.debian.org",
        incoming => "/pub/UploadQueue/",
        # files pass on to dinstall on ftp-master which sends emails itself
        dinstall_runs => 1,
        passive => 1,
};

Archive signing key
Please see ziyi-sarge.asc for sarge, and etch-volatile.asc for etch.

Installation times
Unlike on ftp-master, there are not really fixed dinstall times on volatile. dinstall is run every 15 minutes by cron. First, any changes file in the upload directory is checked. If there is any changes file in queue/accepted after the check (means: at least one package is accepted from the unchecked directory, or was accepted by hand from the new queue) or any volatilemaster gives a hint to run dinstall in any case, dinstall is run and mirrors are synced after the run.

Contacts
The generic contact address (for new packages, ...) is the mailing list debian-volatile@lists.debian.org.

If you want to subscribe to that list, please see http://lists.debian.org/debian-volatile for details.