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

Bits from the release team: full steam ahead towards buster



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi,

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).

Workforce
=========

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
release:

 * 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
welcome!

For the Release Team,
  Emilio
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEcJymx+vmJZxd92Q+nUbEiOQ2gwIFAlrU6pYACgkQnUbEiOQ2
gwLliA/9F57ykmF5MezCBA5STwMaOZVYNH7h15e3+yHXvJAoKL1NyuvRsYXWqBXN
f5i3pzLy48PY0RuMtUlvtgaHu80gWSEmOJXNSnJ5ruXLWdSkAkLeRZvG0HSF3dl6
XnKDAzvBX5Z230eP9+d09eyu4fORDBsLQfRP6Q8BfNig0pAUa8dcMVrN+oAVUxHu
mxQqNajK/qj7JGPjk7ElOPUPsyoeWvtXJct7bn00w12+BY6mdigNSmjj/heavYSb
PX/iDifX/nOvYN5sr1xSociqJDTIUJirVPz6ExbsCWinWjqfgW7ZQiItY0/VpORj
u6UMM4DzRglNzjq/mCJPC5xvyn2a3r9D50w2U0asZAeXYDln2lIBbmnC+Rcwp3ir
dw7mw691oavtYht+qNcHDXaev5MBZuFfQH2KkuctqZc98XamSoc1N6PNYlpkXfXT
ZXeF2n7k0ccdvjAV9XQno4IF9MJbabGIBC0+CBDKrBks6DGveggf+ZkYekFyb4eS
0WVyz7VL4c3Xb2fREpHGuVnb+Ih731VCOANffPD8UCWeAZYe64rqzEGwR6uEwk7e
ZQU+avnyvxuTIPiv9g9mtLtnGjTOpfc7UQDk/fzi4H2oFaGf/04lr/vKloAp7wns
nb3RCzHKl4QacgaFCL7KuxBmSZHFTiLeic3fTOZpiDpNY3KY5rI=
=Yb44
-----END PGP SIGNATURE-----


Reply to: