[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