[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [address@hidden: platform-testers]
From: |
Bruno Haible |
Subject: |
Re: [address@hidden: platform-testers] |
Date: |
Sat, 29 Aug 2020 13:59:56 +0200 |
User-agent: |
KMail/5.1.3 (Linux/4.4.0-186-generic; KDE/5.18.0; x86_64; ; ) |
> ----- Forwarded message from Jeffrey Walton <noloader@gmail.com> -----
>
> Maybe the GNU Coding Standards should (1) tell a maintainer to build a
> release candidate before a release, and (2) make an announcement on
> platform-testers . Currently neither platform-testers nor release
> candidates are discussed in the manual. [1]
>
>
> This particular [testing] problem is not limited to [one project]. Other
> projects do the same, and they also find they have problems after a
> release.
>
> In the post-mortem analysis, this is a procedural problem in the
> release process. The release process has gaps and needs a control to
> contain the risk. In this case I think the control to place is:
> document release candidate testing in the manual. That puts everyone
> on the same page and ensures some coverage to catch some of these
> problems.
>
> Jeff
>
>
> ----- End forwarded message -----
The GNU Maintainers Guide chapter 3 [1] contains a reference to [2], which
contains information about this mailing list.
But surely it's hard to find. So here are a couple of suggestions:
* In the GNU Coding Standards, there is a chapter "The Release Process".
The title of this chapter is a misnomer. It should better be
"What a Release Tarball should look like". Because what this chapter
describes are the expectations regarding a release tarball, not really
the process of preparing it.
* In the GNU Maintainers Guide, it would be useful to have a chapter
"The Release Process", that concentrates on the steps to be done when
preparing a release - only as far as such steps apply to many GNU packages.
Possibly it could mention the following points:
- Frequency of releases (e.g. why not making a release for 5 years is not a
best practice),
- Pointers to pre-release testing [2],
- For internationalized packages: notifying the Translation Project [3][4],
- How a release is marked in the git repository,
- Announcing on info-gnu; reference to gnulib/build-aux/announce-gen.
The existing chapter "Distributions" covers a part of the release
process already, but is focused on the infrastructure (ftp.gnu.org,
alpha.gnu.org, and the info-gnu mailing list), not on the release process
as such.
Bruno
[1] https://www.gnu.org/prep/maintain/html_node/GNU-Accounts-and-Resources.html
[2] https://www.gnu.org/software/devel.html
[3] https://www.gnu.org/software/gettext/manual/html_node/Prerequisites.html
[4] https://translationproject.org/html/maintainers.html