release branch patches, ... and m4 problem

[Jeffrey A Law]

  In message < 9802101935.AA10394@bacchus.pc1.uni-duesseldorf.de >you write:
  > Yes, that's fine. I missed that message - stupid since looking into the
  > archiv and finding about 10 messages having that _subject_ - sorry.
It happens.   Hopefully we'll have search capability for the archive
soon, so that looking this stuff up isn't quite so painful (yes, someone
is working on it :-)

  > Still, I initially was wondering wether it is possible to mark some of the
  > patches that come in during development (at any time, not just now) as
  > beeing important and reliable enough to call them something like 'release
  > branch patches'
We already do that to some extent.  Or more correctly the various maintainers
are doing that; Craig & Toon are letting me know about critical g77 bugs, Jason
is marking critical G++ patches, etc.  That's how we end up with a set of 
patches to call 1.0.2 :-)

I don't think it's really feasible to do this on a global scale all the time;
takes too much time.  Particularly as the development sources move further
and further away from the current release sources -- it gets harder and harder
to determine what patches will apply, whether or not they're correct for the
release (due to dependencies on other patches for example), etc.

This is why we want to get a few minor releases out quickly (1.0.x series)
then get started on 1.1 -- after a while it simply becomes too difficult
to continue maintenance on the 1.0.x series.

  > Are you installing all patches in the release branch or are you doing what
  > I just tried to desceibe (v.s.).
Just the critical patches for the 1.0.2 release

  > Switching context:
  > 
[ ... ]

  > The cvs sources (updated today) complain on compilation that I need to
  > provide GNU m4 > v1.1, cause it's using the system m4.
  > Shouldn't it find the gm4 that is in the path before the system m4 that's
  > later in the path ?
This is autoconf that's complaining.  I don't know how autoconf works, so
I can't really say with authority what the correct behavior of autoconf
should be in this case.

jeff