This is the mail archive of the gcc@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 format: [Raw text]

Re: auto-sync of top-level 'include' & 'config' directories?



> As for the "shared" directories: config from gcc has mt-alphaieee,
> config from src has mt-s390pic and mh-s390pic, and include from src has
> 184 more files than gcc.

Include is not a problem.  I've said that MANY times and it hasn't
sunk in yet.  The libiberty and include directories are already as
in-sync as they're going to get, and an auto-sync cron job keeps them
that way.

> If there are no strong feelings, what about gcc being the config
> master and src the include master, with a README.COMMON stating:

Include is not a problem.  GCC will remain the include master for the
files that are common (they're part of libiberty), and the files that
aren't common will remain only in src.

> - patches to include and config must be sent to both xxx-patches
>   mailing lists

There is no single mailing list for src.  I send to about five
separate project lists when I have a common patch for them, but
they've all pretty much agreed to let me handle the libiberty/include
merges the way I've been doing it.

> - approval by an authorized person on one of the projects is enough to
>   commit, if not urgent or new, both approval being better but not
>   required so patches do not stay stuck forever

This isn't needed.  I have suitable permissions on both sides to
handle the commits and merges myself, and there is already existing
policy in place about files mastered elsewhere (libtool,
config.guess).

> - if there's a problem or conflict about a patch, assume that it can
>   be resolved afterwards by talking

GCC already has procedures for resolving patch problems.  They apply
equally well to problems gcc causes in other projects.

> - a bot does the sync every hour or so or automatically at commit

No.  I review every patch before merging, because it's not safe to
truly auto-merge changes that way.

> - if there's a lasting conflict, the bot is extended with code to read
>   gcc/do-not-want-from-src.txt and src/do-not-want-from-gcc.txt and exclude
>   appropriate files from auto-sync so that both project can endlessly flame
>   each other

I'd rather see an inclusion list in the bot, rather than an exclusion
list, so that new things don't mysteriously appear on the other side.


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