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

Bits from the Stable Release Managers



Hi,

Introduction
============

The Stable Release Managers, with the support of the rest of the Release Team,
are responsible for updates to the stable release (and oldstable while that
suite is also being supported by the Security Team), via point releases and
the stable-updates mechanism [STABLE-UPDATES].

You can see the current status of proposed updates to stable via our BTS
pseudo-package [BTS] and our tracking website. [QUEUE-VIEWER]

Workflow updates
================

Historically, the workflow for stable updates has been to file a bug against
the release.debian.org pseudo-package and wait for confirmation from a member
of the Release Team before proceeding with the upload. We're aware that the
time before a response can sometimes be quite long and that, in any case,
having to perform the upload at a later point can be inconvenient.

We are therefore introducing a slight change to the process, which we hope will
benefit both you and us - if you are confident that the upload will be accepted
without changes, please feel free to upload at the same time as filing the
release.debian.org bug. If you're unsure about the changes or would like
further guidance or discussion, then simply wait for a response as now. Please
continue to file the bug in any case, both for tracking purposes and a location
for discussion should any turn out to be required.

Alongside this, we are considering an update to the templates used by reportbug,
to capture more information regarding the changes, testing, impact and so on.
This will assist us in triaging updates and hopefully avoid round trips to
collect the information.

Update criteria
===============

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

   * The bug you want to fix in stable must be fixed in unstable
     already (and not waiting in NEW or the delayed queue)
   * 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 for jessie or +deb9u1 for stretch) 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) [SECURITY-TRACKER]

Please don't post a message on the debian-release 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.

Thanks,

Adam,
for the SRMs

[BTS] https://bugs.debian.org/release.debian.org
[QUEUE-VIEWER] https://release.debian.org/proposed-updates/stable.html
[SECURITY-TRACKER] https://security-tracker.debian.org/
[STABLE-UPDATES] https://lists.debian.org/debian-devel-announce/2011/03/msg00010.html

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


Reply to: