Adam D. Barratt has announced that the first point release for Debian GNU/Linux 10 has been scheduled for 7th September 2019

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-
PDATES].

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

First 'buster' point release
============================

The first point release for Debian 10 has been scheduled for 7th
September 2019. That is slightly later after buster's initial release
than we would normally aim for, but an earlier date has proved
difficult with DebConf and holidays.

A point release for 'stretch', Debian 9.10, will also take place on the
same day.

Following the release of 10.1, we will continue to aim for stable point
releases on an approximately two-month basis, and oldstable every three
to four months.

As always, the first update to a new release is very busy, so we ask
for your patience if you are still awaiting a reply to an upload
request. It may be that an update to your package is deferred to a
later point release purely from a workload perspective; more serious or
more urgent fixes will be prioritised.

Workflow
========

Uploads to a supported stable release should target their suite name in
the changelog, i.e. 'buster' or 'stretch'. You should normally use
reportbug and the release.debian.org pseudo-package to send a *source*
debdiff, rationale and associated bug numbers to the Stable Release
Managers, and await a request to upload or further information.

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. However if you are new to the process, we would
recommend getting approval before uploading so you get a chance to see
if your expectations align with ours.

Either way, there must be an accompanying bug for tracking, and your
upload must comply with the acceptance criteria below.

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. ...+deb10u1 for buster 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.

We make extensive use of usertags to sort and manage requests, so
unless you particularly enjoy crafting bug meta-data, reportbug is
generally the best way of generating your request. Incorrectly tagged
reports may take longer to be noticed and processed.

Thanks,

Adam,
for the SRMs