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

Bits from the Stable Release Managers


We've just announced the date for the first Jessie point release [81ANN]
so it seems a good time for a quick recap of the process around updates
in (old)stable.

Here's a reminder of our usual criteria for accepting fixes. These are
designed to make the process smooth and frustration-free for both us and

   * The bug you want to fix in stable must be fixed in unstable
     already (and not waiting in NEW)
   * The bug should be of severity "important" or higher
   * Bug meta-data - particularly affected versions - must be
     up to date
   * Fixes must be minimal and relevant and include a sufficiently
     detailed changelog entry
   * A source debdiff of the proposed change must be included
     in your request (not just the raw patches or "a debdiff
     can be found at $URL")
   * The proposed package must have a correct version number
     (e.g. ...+deb8u1) and you should be able to explain what
     testing it has had
   * The update must be built in an (old)stable environment or chroot
   * Fixes for security issues should be co-ordinated with the
     Security Team, unless they have explicitly stated that they
     will not issue an DSA for the bug (e.g. via a "no-dsa" marker
     in the Security Tracker)

Please don't post a message on the mailing list and expect it not to get
lost - there must be a bug report against release.debian.org.  Unless
you particularly enjoy crafting bug meta-data, reportbug is generally
the best way of generating your request.

Due to the way that the archive manages uploads to proposed-updates, if
you upload a .changes file which only includes source and
architecture:all packages, please ensure that you rename it to something
other than "_$arch.changes".

Thanks for helping us take care of our stable releases.

for the SRMs


Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: