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

Bits from the release team: full steam ahead towards buster

Hash: SHA256


We are about halfway through the buster development cycle, and a release
update was overdue.

Architecture Qualification

We plan to remove some of the human element from evaluating architectures
by deriving some of the information empirically. This is a draft proposal at
this stage, not a fully-formed plan.

Feedback about package auto-removals from testing has been largely positive,
so we plan to use some of the same principles here.

The implementation will be in two stages:
  * first, determine the parameters and implement the evaluation process
  * later, automatically demote an architecture after a suitable notice period

We anticipate that some parameters for buster might include:
  * buildd queue
  * package installability (from britney)
  * arch-specific bugs (from new BTS tags)
  * arch-specific migration issues

For bullseye, we would like to include automated QA coverage (piuparts, CI,
autopkgtests, and so on).


We have identified some areas where we would appreciate help, and which do not
require privileged access (or even to be a DD). They are:

  * Hacking on our tooling
  * Reviewing stable requests (and unblocks during freeze)
  * Coordination and communication
  * Documentation

We have chosen these because (in the first two cases) they lend themselves to
self-contained work units without a long-term investment, or (in the latter)
they are more administrative and might appeal more.

Please look out for more detailed requests for help later as we refine these
ideas, but do not hesitate to get involved now if you would like to.

Streamlining proposed-updates

We are streamlining uploads to the stable and oldstable suites slightly, with
the intention of reducing round-trips.

More details will be included in a further mail in the near future.

Testing of proposed-updates

We're seeking to expand automated testing of {old-,}proposed-updates for
improved QA before point releases.

"Buster" Release Timetable

The following is an overview of the milestone dates for the buster freeze and

 * 2019-01-12 - Transition freeze
 * 2019-02-12 - Soft-freeze
 * 2019-03-12 - Full-freeze

In order to minimize the freeze length, we have shortened the transition freeze by one
month. In any case, if you are planning a transition, don't leave it until
the last moment, or else it may not make it in time for buster. The larger
the transition is, the earlier it should happen.

We do not have a fixed release date, but given the cadence of previous
releases it is likely that the release date will be some time mid
2019.  We certainly hope to improve the length of the full freeze and
you can help with that by ensuring that you are ready for these milestones.

The milestones in more detail:

| Effect \ Milestone  |       Transition freeze       |     Soft-freeze     |     Full-freeze    |
| Major transitions   |  No new transitions           |          No         |         No         |
| Migration age req.  |  Standard (2/5/10d)           |     10 day delay    | Standard (2/5/10d) |
| New src packages    |  Standard automatic migration |          No         |         No         |
| Re-entry to testing |  Standard automatic migration |          No         |         No         |
| Migration rules     |  Standard automatic migration | Some manual reviews | 100% manual review |

The above is subject to changes and may be be overridden on a case-by-case
basis, where deemed necessary by the release team.

Please have your packages release ready by the time of the transition freeze.

Future codenames

During the Release Team sprint in Cambridge, it was decided that Debian 12
will be codenamed "bookworm".

Feedback for the stretch release

We are always thinking about how to improve the release process. Therefore if
you have any feedback on how the stretch cycle went, any suggestions on how to
improve it, any comments on what we did well or what we can improve, or
anything else related, please send us a mail to debian-release@lists.debian.org
(or team@release.debian.org if you would like to keep it private). All input is

For the Release Team,


Reply to: