This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

other/3161: Release tarball issues



>Number:         3161
>Category:       other
>Synopsis:       Release tarball issues
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Jun 13 03:26:00 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator:     Joseph S. Myers
>Release:        3.0 20010611 (prerelease)
>Organization:
none
>Environment:
System: Linux digraph 2.2.19 #1 Wed Mar 28 16:01:38 UTC 2001 i686 unknown
Architecture: i686

	
host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: ../gcc-3.0-20010611/configure --prefix=/opt/gcc/3.0-pre --enable-shared --enable-threads=posix --with-system-zlib
>Description:

The following are issues with the prerelease tarball distribution;
though mostly not release critical, they ought to be fixed for the
release:

* The files in the tarball are not world-readable.  According to the
  GNU Coding Standards, they ought to be.  (They ought to be anyway,
  even if we ignore the other statements there that directories should
  be mode 777 and filenames no more than 14 characters.)

* The HTML installation instructions are not present in the INSTALL
  directory.

* The files bugs.html and gnats.html ought to be included in the
  release tarball, so users have reasonably current bug reporting
  instructions there.  (If converted on time, faq.html should be
  included as well.)

* .bz2 files should be generated; I previously added support for this
  to the release script.

The following should be done for the release proper (not
pre-releases), and don't yet seem to be covered in the release script:

* ChangeLogs on the release branch should be updated just before the
  release to mark in each ChangeLog the point at which the release was
  made.  (See /home/law/egcs/update_changelogs on gcc.gnu.org.)
  Similarly, version.c files should be updated to record the status as
  "release" rather than "prerelease".  (And then changed back to
  "prerelease", version 3.0.1, immediately after the release is made.)

* The file gcc/NEWS should be regenerated (on the branch; it may as
  well be regenerated on the mainline as well) from the then current
  release notes, with contrib/gennews, just before the release is
  made.

>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]