Bookworm release planned on 2023-06-10 and the last weeks up to the release

[Moderator Brian Masinick]

https://www.antixforum.com/forums/topic/debian-bookworm-installer-rc1/#post-1055

Release date
============

We plan to release on 2023-06-10.

If you want to celebrate it, please consider attending a Debian
release party, or hosting your own! See
https://wiki.debian.org/ReleasePartyBookworm for more information.
(Note: the release process typically takes the whole day and the
release isn’t done until the early hours of Sunday UTC.)

Full Freeze date
================

With the release date set, it’s time to announce the Full Freeze [1]
date: Wednesday 2023-05-24. This means that from that moment on, every
package requires a manual unblock [2] by the release team if it needs
to migrate to bookworm. Please note that, as with all freezes, the new
rules apply for all packages that haven’t migrated to testing yet (not
only for uploads after the freeze).

For all uploads, please review the Freeze Policy [1] once again to
make sure you know what is appropriate at this phase of the release.

The final weeks up to the release
=================================

In the last week prior to the freeze, testing will be completely
frozen and only emergency bug fixes will be considered in this period.
Please consider Sunday 2023-05-28 at 12:00 UTC the absolute last
moment for submitting unblock requests for bookworm.

Changes that are not ready to migrate [3] to testing at that time will
not be included in bookworm for the initial release. However, you can
still fix bugs in bookworm via point releases if the changeset follows
the rules for updates in stable.

Upgrade testing
===============

If you are in a position to carry out upgrade testing from bullseye to
bookworm in the field, now is the time to do so and send your feedback
as a bug report against the “upgrade-reports” pseudo-package.

Release notes
=============

Please ensure that any information about your packages which should
form part of the release notes is prepared in plenty of time to allow
for review and translations. Release notes coordination happens in the
BTS in bugs filed against the “release-notes” pseudo-package and in
merge requests on salsa [4].

For the release team,
Paul

[1] https://release.debian.org/testing/freeze_policy.html#full
[2] please use $(reportbug release.debian.org) to get the tags and
template right
[3] The testing migration excuses must not mention *blocked* (due to
dependency issues, CI or piuparts failures or other reasons). It is
acceptable if the required age has not been reached at this time.
[4] https://salsa.debian.org/ddp-team/release-notes/

--
Brian Masinick

[Member Xunzi_23]

Helpful

Up

0

::

Thanks for Info Brian.

It seems as usual some packages will be historic on release date.

Unfortunate for many users flagship application Libreoffice.

Version 4.7.5 was released in September 2022 and is still languishing
in Debian Experimental today.

Presently direct installation from LO Org is the only way to have an up to date
version with many improvements and bug fixes.

A second maintenance update to 7.5.2 was released by LO Org on 30 March 2023.

[Member blur13]

Helpful

Up

0

::

“It seems as usual some packages will be historic on release date.”

This is the Debian way. Hate it or love, this is what makes Debian “stable” stable.

[Moderator Brian Masinick]

Helpful

Up

0

::

The reason why certain packages are really old besides stability is that certain projects are either lacking enough help (the most likely reason) or the participants have additional responsibility.

Another common reason for late projects is that the release date of the package or project doesn’t align well with the project dates.

My guess with Libreoffice is that it’s a large effort. To build the entire thing in itself is a big endeavor. Speaking of Endeavour OS, while many packages are put together into binaries, they have a convenient code building scheme in their AUR community packages and the yay tool.

Procedurally it’s easy to build software. Timewise and organizationally it’s a much more involved matter, even though it’s pretty well documented and defined. You still have to build a LOT of code, keep an inventory of the [packages, libraries, tools, directories], and oh yes, there’s the matter of verification and testing. With something as comprehensive as LibreOffice it’s really a big deal.

If anyone is able to help, projects like that ALWAYS need more volunteers, just as we do.

--
Brian Masinick

[Moderator Brian Masinick]

Helpful

Up

0

::

I have not been a developer or maintainer of software since the mid ninties; I have been a tester and a test coordinator since then and those are also time consuming jobs with much more to do than most people would realize.

Put them both together and you may get a rough idea of the effort involved. Most free software is 90% volunteer. Debian has a few isolated teams that are hired and paid for some work. That’s a very small fraction of the number of things that are done. I doubt that LibreOffice is one of the compensated efforts because the funds are specific to particular distribution goals and they definitely don’t cover more than a couple of things, mostly hardware and only priority work requiring extra attention.

--
Brian Masinick

[Author]

Posts