Differences between revisions 12 and 13
Revision 12 as of 2013-02-28 11:05:31
Size: 2766
Editor: MehdiDogguy
Comment: doc about ben's query language
Revision 13 as of 2014-12-14 05:43:27
Size: 2794
Editor: BenFinney
Comment: Distinguish “bug report” (report and discussion) from “bug” (the flaw itself).
Deletions are marked like this. Additions are marked like this.
Line 6: Line 6:
transition bug against release.debian.org (reportbug has a template). transition bug report against release.debian.org (reportbug has a template).
Line 10: Line 10:
In the transition bug, please include the list of affected source packages
and what needs to be done with each of them.  In some cases, a lot of
binNMUs will be enough (e.g. a clean library ABI bump) though in other
cases sourceful uploads are required (e.g. API change).
In the transition bug report, please include the list of affected
source packages and what needs to be done with each of them. In some
cases, a lot of binNMUs will be enough (e.g. a clean library ABI bump)
though in other
cases sourceful uploads are required (e.g. API
change).
Line 19: Line 20:
The release team will (based on your input) setup a transition page for
the transition (see http://release.debian.org/transitions/).  This page
can be used to help tracking the progress of the transition after it
starts. It is also common to "block" the transition bug by FTBFS (and
other) bugs that are (or could end up) stalling the transitions.
The release team will (based on your input) setup a transition page
for the transition (see http://release.debian.org/transitions/). This
page
can be used to help tracking the progress of the transition after
it
starts. It is also common to "block" the transition bug report by
FTBFS (and other) bugs that are (or could end up) stalling the
transitions.
Line 34: Line 36:
 * Reference the transition bug. People tend to ask if you don't. :)  * Reference the transition bug report. People tend to ask if you don't. :)

Transitions

Workflow

Please request a transition slot from the Release Team by filing a transition bug report against release.debian.org (reportbug has a template). In some cases, it might be prudent to also send an email to debian-devel-announce, but please see the section below on that subject.

In the transition bug report, please include the list of affected source packages and what needs to be done with each of them. In some cases, a lot of binNMUs will be enough (e.g. a clean library ABI bump) though in other cases sourceful uploads are required (e.g. API change).

Please do not upload the package to unstable without approval from the release team. In the meantime, you are more than welcome (and even encouraged) to use experimental.

The release team will (based on your input) setup a transition page for the transition (see http://release.debian.org/transitions/). This page can be used to help tracking the progress of the transition after it starts. It is also common to "block" the transition bug report by FTBFS (and other) bugs that are (or could end up) stalling the transitions.

Until the transition finishes, please be prepared to help out fixing outstanding issues with the transition. This includes checking build statuses, finding (bin)NMU or RM candidates.

debian-devel-announce mails

If you are sending an email to d-d-a about the transition, here are some recommendations.

  • Reference the transition bug report. People tend to ask if you don't. :)

  • Avoid using specific upload dates, unless they have been approved by the Release Team.
    • We do not like NACK'ing a d-d-a mail on d-d-a. It just isn't pretty, but it is far better than entangled transitions.

Speeding up transitions

Here are some hints to getting your transitions started and finished sooner.

  • Include a sample "ben" file in your transition mail.

    • See documentation about the query language here

    • reportbug support: #672722

  • Check your reverse dependencies:
    • Find RC-buggy reverse dependencies.
      • Not in testing => not a blocker (but list them anyway, so we know).

      • In testing => may need NMU or RM.

    • Build tests to catch FTBFS.
      • Use severity important (and bump to serious when the transition starts)
  • Find the relevant migration guides or/and patches for your reverse dependencies (if any).
  • Avoid changing the name of -dev packages. It means sourceful uploads and that tends to be painfully slow.
    • Provides sometimes works, but not for versioned build depends.
  • Be prepared to NMU some of your reverse dependencies.