bug-standards
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [address@hidden: platform-testers]


From: Jose E. Marchesi
Subject: Re: [address@hidden: platform-testers]
Date: Sun, 30 Aug 2020 12:46:00 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

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

+1



reply via email to

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