bug-standards
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]