Re: Reapply patch lost during recent "blind import" of libtool

[Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>]

Alexandre> Is there any place where we can document that patches
Alexandre> for libtool files should not be checked in in the GCC
Alexandre> tree before being installed in the libtool CVS tree,
Alexandre> even when they come from people with global write
Alexandre> privs?

> Well, if folks agree with this policy, I'd be happy to post a patch
> myself :-)

I am happy with your proposed change in policy.  I am also ACKing that
I read <orzodmaevt.fsf@guarana.lsd.ic.unicamp.br>, the message with
the actual documentation patch.

In addition to any English description, a good place to document this
policy might be in CVSROOT/commitinfo and a supporting script script.
We could write a simple rule in commitinfo to help enforce this policy
and the existing policy which covers config.guess (this example could
be extended to handle other special cases mentioned in your policy
documentation patch):

/cvs/gcc/.* true
/cvs/gcc check-import

Here is a sample check-import:

#!/bin/sh

W1="WARNING: This file should be upgraded from the related external"
W2="WARNING: master source repository using 'cvs import'."
W3="WARNING: See http://gcc.gnu.org/codingconventions.html for details."

shift; for i in $*; do case $i in
  config.guess) echo $W1; echo $W2; echo $W3; exit 1;;
  config.sub) echo $W1; echo $W2; echo $W3; exit 1;;
  ltconfig) echo $W1; echo $W2; echo $W3; exit 1;;
  ltmain.sh) echo $W1; echo $W2; echo $W3; exit 1;;
  libtool.m4) echo $W1; echo $W2; echo $W3; exit 1;;
  ltcf-*.sh) echo $W1; echo $W2; echo $W3; exit 1;;
esac; done

Here is the sample session using this approach (I set this up locally,
but used client/server CVS to ensure it would work the same remotely
to gcc.gnu.org):

; cvs ci -m '' ltconfig 
WARNING: This file should be upgraded from the related external
cvs server: Pre-commit check failed
WARNING: master source repository using 'cvs import'.
WARNING: See http://gcc.gnu.org/codingconventions.html for details.
cvs [server aborted]: correct above errors first!

Here is a correct way to use CVS vendor branches with the above policy
rules (this example for libtool only, but config.guess, etc should be
similar):

1. Create an empty directory (i.e. do not work in a checked-out CVS
   working tree).  Populate it with upgraded libtool files taken from
   the master repository on subversion.gnu.org.

2. Run: cvs import /cvs/gcc SUBVERSION LIBTOOL_RELEASE_NUMBER
   within the directory populated in step 1.

3. Ignore any merge warnings the first time this is done.

4. Run: cvs admin -bSUBVERSION ltconfig ltmain.sh libtool.m4 ltcf-*.sh
   at the top level of a checked-out CVS working tree.

http://gcc.gnu.org/cvswrite.html says that:

``Maintainers are free to import files maintained outside the tree from
  their official versions without explicit write approval. Such files
  would include config.guess and config.sub.''

It appears that the usage of the word import in that context was not
taken literally as in ``cvs import'' since I see all changes on
config.guess were brought in via the standard `cvs ci'' mechanism.
The same is true of libtool.  One begins to see why merging in from
external sources is reported to be such a pain. ;-)

Now, I don't want to discount an important point that was indirectly
raised by Robert Boehne.  The gcc source tree is only using a
"post-processed" version of libtool thus it might not be appropriate
to ever allow local changes, but that fact does not discount the value
of using CVS vendor branches properly in conjunction with a commitinfo
script to help watch for mistakes.

Regards,
Loren
-- 
Loren J. Rittle
Senior Staff Software Engineer, Distributed Object Technology Lab
Networks and Infrastructure Research Lab (IL02/2240), Motorola Labs
rittle@rsch.comm.mot.com, KeyID: 2048/ADCE34A5, FDC0292446937F2A240BC07D42763672