[binutils-gdb] Add README file for creating binutils releases

[Nick Clifton <nickc at sourceware dot org>]

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=78b2179a8e085b34ad7872450e5fadff4f7e5eb0

commit 78b2179a8e085b34ad7872450e5fadff4f7e5eb0
Author: Nick Clifton <nickc@redhat.com>
Date:   Tue Sep 26 10:07:23 2017 +0100

    Add README file for creating binutils releases

Diff:
---
 binutils/ChangeLog                    |   4 +
 binutils/README-how-to-make-a-release | 135 ++++++++++++++++++++++++++++++++++
 2 files changed, 139 insertions(+)

diff --git a/binutils/ChangeLog b/binutils/ChangeLog
index 2b50930..80fff9c 100644
--- a/binutils/ChangeLog
+++ b/binutils/ChangeLog
@@ -1,3 +1,7 @@
+2017-09-26  Nick Clifton  <nickc@redhat.com>
+
+	* README-how-to-make-a-release: New file.
+
 2017-09-26  Alan Modra  <amodra@gmail.com>
 
 	PR 21732
diff --git a/binutils/README-how-to-make-a-release b/binutils/README-how-to-make-a-release
new file mode 100644
index 0000000..da0e8a8
--- /dev/null
+++ b/binutils/README-how-to-make-a-release
@@ -0,0 +1,135 @@
+		README for MAKING BINUTILS RELEASES
+	
+This is a collection of notes on how to perform a binutils release.  A
+lot of this information can also be found in the maintain.texi file in
+the gnulib project:
+
+  https://www.gnu.org/software/gnulib/
+
+It is useful to have a cloned copy of the sources of this project as
+it also contains an upload script used to install tarballs on the GNU
+FTP server.
+
+Make sure that you have upload authority on sourceware and fencepost.
+Beware - this is an involved process and can take weeks to complete.
+See the maintain.texi file for details on how to obtain these
+permissions.
+
+-------------------------------------------------
+How to perform a release.
+-------------------------------------------------
+
+xxx -- fill in stuff here -- xxx
+
+-------------------------------------------------
+How to perform a point release.
+-------------------------------------------------
+
+A point release is easier than a normal release since a lot of the
+work has already been done.  The branch has been created, the
+translations updated and the documentation uploaded.  So the procedure
+looks like this:
+
+  0. Decide that a point release is necessary.
+
+     Usually this only happens when a sufficient number of serious
+     bugs have been found and fixed since the previous release, and a
+     new official release is not imminent.
+
+  1. Tell the community that a point release is happening.  Ask
+     maintainers to ensure that their ports are up to date on the
+     release branch.  Ask the community if there are any bug fixes
+     which are missing from the branch.  Allow some time for the
+     responses to this step.
+
+  2. Make sure that the branch sources build, test and install
+     correctly.
+
+  3. In the branch sources...
+  
+       Update the minor release number in bfd/version.m4.
+       Regenerate the configure files.
+       Commit the updates along with a "this-is-the-2.XX.X-release" note
+       in the changelogs.
+     
+  4. Tag the branch with the new release number:
+
+        git tag -a binutils-2_XX_X
+	  [optional -u XXXXX to sign with a gpg key]
+	  [optional -f to move an already created tag]
+	  
+	git push origin
+
+  5. Create the release tarballs:
+
+       a. Edit bfd/development.sh and set "development=false".
+       b. ./src-release -b -g -l -x binutils
+       c. Edit bfd/development.sh and set "development=true".
+
+     FIXME: Really the development.sh file should be changed by the
+     src-release script on the fly.  The development=false flag only
+     wants to be set in the release tarballs however, not the branch
+     sources as the branch will continue to have (development) patches
+     checked in to it.
+
+     FIXME: The tarballs will contain spurious autom4te.cache
+     directories which could be removed to reduce their size.
+
+  6. [If paranoid - upload the tarballs to one of the FTP servers and
+      ask people to test it before going on to step 7].
+      
+  7. Upload the tarballs to ftp.gnu.org.
+
+       gnupload --to ftp.gnu.org:binutils binutils-X.XX.X.tar.*
+
+     gnupload is in the gnulib/build-aux directory.
+
+  8. Upload the tarballs to sourceware.org:
+
+       sftp sourceware.org
+         cd /ftp/pub/binutils/releases
+ 	 put binutils-X.XX.X.tar.*
+ 	 chmod 644 binutils-X.XX.X.tar.*
+	 quit
+
+    FIXME: Should the signatures (created by the gnupload script in
+    step 7) be uploaded as well ?
+
+  9. Clean up the source tree.  (Use "git status" to find new files,
+     and remove them).
+  
+  10. Update web pages.  For sourceware.org:
+
+      * Log on to sourceware.org
+      * Go /www/htdocs/binutils
+      * Edit index.html
+
+      For the www.gnu.org site you have to email webmasters@gnu.org
+      and ask them to make the change(s).
+
+  11. Send an emails to the binutils list, info-gnu@gnu.org and
+      David Edelsohn <dje.gcc@gmail.com> announcing the new release.
+      (The email to Davis is so that he can update the GNU Toolchain
+      social media).  Something like this:
+------------------------------------------------------------------------
+Hi Everyone,
+
+  We are pleased to announce that version 2.XX.X of the Binutils project
+  sources have been released and are now available for download at:
+  
+    https://ftp.gnu.org/gnu/binutils
+    https://sourceware.org/pub/binutils/releases/
+
+  This is a point release over the previous 2.XX version, containing bug
+  fixes but no new features.
+
+  Our thanks go out to all of the binutils contributors, past and
+  present, for helping to make this release possible.
+--------------------------------------------------------------------------
+
+
+Copyright (C) 2017 Free Software Foundation, Inc.
+
+Copying and distribution of this file, with or without modification,
+are permitted in any medium without royalty provided the copyright
+notice and this notice are preserved.