>> ----- Forwarded message from Jeffrey Walton <[email protected]> ----- >> >> 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
