🚀 go-pugleaf

I (and I'm sure a lot of others) have problems keeping
up with the often large numbers of patches posted to fix
Gnu software, esp. g++ and gcc. Once a complete release
is made (such as gcc 1.37.x) I have confidence that the
release has the known bugs fixed, but often patches are
posted to allow compilation on a new OS release (note the
changes needed for SunOS 4.1), or as a result of a
concentration of effort on a particular architecture (witness
the recent Meissner patches from OSF). Whilst I may not
need these patches immediately, in the future it may come
about that I will (e.g. compiling gcc on a new machine we
just bought).

I would very much like to keep the software up to date
at a finer granularity than major releases, but problems
occur if you miss one patch, or you find conflicting
patches, or broken patches are posted. Another problem
is that I know of no archive site that keeps patched
releases beyond the base release, and anyway that means
I would have to ftp new releases (or diffs) regularly, some
of which may not pertain to the architectures I use.

Anyway, perhaps what we need is a separate news group
that may be archived by archive servers, which contains
patches to gnu software; this news group may well be
moderated to make sure posted patches are OK, or at least
found to be consistent with FSF ongoing work. It may
work in a number of ways:

1)  A number of news groups, one for each major software
    area, e.g.
         gnu.patches.gcc
         gnu.patches.g++
         gnu.patches.binutils

    The Archive-Name: header could be used to save patches under
    the release number of the utility:

           Archive-Name: gcc-1.37/p1234     .. or
           Archive-Name: 1.37/p1234         etc.

    The advantage of having separate groups is that each
    may be separately moderated. If someone from FSF was to
    moderate the gcc group (for instance) than a patch
    number may be assigned and the patch may become an official
    change to that revision. At least major problems could be
    fixed without having to resort to waiting for a new release.
    A good example was the problem that broke gcc 1.36 on the 68k
    so that X wouldn't work (but 1.35 and 1.37 were OK).

2)  One news group, using the Archive-Name to group the patches
    into the appropriate utility:

        Archive-Name: gcc/1.37/p1234     .. or
        Archive-Name: gcc-1.37/patches/p1234

    The last form would allow direct archiving into a directory
    containing the gcc source, under a patches subdirectory.

If the news group(s) were unmoderated, then a problem with
naming may arise. If so, then a convention of prepending the
patch name with the originator may be adopted e.g.

        Archive-Name: gcc-1.37/patches/mcrae23

This is similar to the Meissner numbering.

If the news group(s) are moderated (especially by the person(s))
organising each release), then a useful method of
tracking bug fixes etc. between each major release is achieved.
A problem is that a moderator may be overwhelmed by the work
of checking each patch or tracking internal changes against
diverged patches etc. New release diffs may even be posted.

How does this sound?

Andrew McRae			inet:	andrew@megadata.mega.oz.au
Megadata Pty Ltd,		uucp:	..!uunet!megadata.mega.oz.au!andrew
North Ryde  2113		Phone:	+61 2 805 0899
NSW    AUSTRALIA		Fax:	+61 2 887 4847