From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19573 invoked by alias); 3 Dec 2001 20:23:50 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 19518 invoked from network); 3 Dec 2001 20:23:42 -0000 Received: from unknown (HELO cygnus.com) (205.180.230.5) by sources.redhat.com with SMTP; 3 Dec 2001 20:23:42 -0000 Received: from greed.delorie.com (cse.cygnus.com [205.180.230.236]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id MAA27069; Mon, 3 Dec 2001 12:23:40 -0800 (PST) Received: (from dj@localhost) by greed.delorie.com (8.11.6/8.11.6) id fB3KLAj06353; Mon, 3 Dec 2001 15:21:10 -0500 Date: Mon, 03 Dec 2001 12:23:00 -0000 Message-Id: <200112032021.fB3KLAj06353@greed.delorie.com> From: DJ Delorie To: guerby@acm.org CC: gcc@gcc.gnu.org In-reply-to: <200112031932.fB3JWU922496@ulmo.localdomain> (guerby@acm.org) Subject: Re: auto-sync of top-level 'include' & 'config' directories? References: <200112022321.fB2NLJD29198@ulmo.localdomain> <200112031657.fB3Gv8a01944@greed.delorie.com> <200112031932.fB3JWU922496@ulmo.localdomain> X-SW-Source: 2001-12/txt/msg00075.txt.bz2 > 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.