[bug#72840] [PATCH RFC v4] doc: Add “Deprecation Policy” section.

[Greg Hogan]

On Mon, Sep 23, 2024 at 6:11 PM Ludovic Courtès <ludo@gnu.org> wrote:
>
> +@item Package removal
> +Packages whose upstream developers have declared as having reached ``end
> +of life'' or being unmaintained may be removed; likewise, packages that
> +have been @b{failing to build for two months or more} may be removed.
> +
> +There is no formal deprecation mechanism for this case, unless a
> +replacement exists, in which case the @code{deprecated-package}
> +procedure mentioned above can be used.
> +
> +If the package being removed is a ``leaf'' (no other packages depend on
> +it), it may be removed after a @b{one-month review period} of the patch
> +removing it (this applies even when the removal has additional
> +motivations such as security problems affecting the package).
> +
> +If it has many dependent packages---as is the case for example with
> +Python version@tie{}2---the relevant team must propose a deprecation
> +removal agenda and seek consensus with other packagers for @b{at least
> +one month}.  It may also invite feedback from the broader user
> +community, for example through a survey.  Removal of all impacted
> +packages may be gradual, spanning multiple months, to accommodate all
> +use cases.
> +
> +When the package being removed is considered popular, whether or not it
> +is a leaf, its deprecation must be announced as an entry in
> +@code{etc/news.scm}.

Hi Ludo',

Is the intent for the news entry to pre-announce the removal of a
popular package, as specified for other kinds of deprecation and
removal? Otherwise, even though we have extended the review period, we
are expecting users to track the mailing lists.

Greg