From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 99606 invoked by alias); 3 May 2016 07:50:54 -0000 Mailing-List: contact libffi-discuss-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libffi-discuss-owner@sourceware.org Received: (qmail 99587 invoked by uid 89); 3 May 2016 07:50:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=urgently, H*Ad:U*libffi-discuss, Green, trusted X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 03 May 2016 07:50:53 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E238780083; Tue, 3 May 2016 07:50:51 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-113-135.phx2.redhat.com [10.3.113.135]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u437oodw013478 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 3 May 2016 03:50:51 -0400 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id u437omE3027298; Tue, 3 May 2016 09:50:48 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id u437okif027297; Tue, 3 May 2016 09:50:46 +0200 Date: Tue, 03 May 2016 07:50:00 -0000 From: Jakub Jelinek To: Andrew Haley Cc: Anthony Green , "libffi-discuss@sourceware.org" Subject: Re: libffi maintenance Message-ID: <20160503075046.GT26501@tucnak.zalov.cz> Reply-To: Jakub Jelinek References: <5728562B.2070408@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5728562B.2070408@redhat.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-IsSubscribed: yes X-SW-Source: 2016/txt/msg00015.txt.bz2 On Tue, May 03, 2016 at 08:41:31AM +0100, Andrew Haley wrote: > On 02/05/16 14:51, Anthony Green wrote: > > In addition, I've granted write permission to three trusted and active > > hackers: Tom Tromey, Richard Henderson and Josh Triplett. I plan on > > spending a little more time on libffi soon, but there's been a log jam > > of PRs over the past year, and I hope this change will help move > > things along. > > We should have the conversation about what to do about the old and > stale libffi in the GCC tree. It's caused me (and probably plenty of > others) a great deal of confusion this year, with various bug fixes > and improvements to merge one way or the other. In particular, I > still don't really know where development happens: some of it happens > in GCC and some in libffi upstream. > > I'd like libffi to be gone from the GCC repo, but that's probably not > possible. I intend to delete libgcj, but I think that gccgo still > uses libffi. We have several other libraries in the GCC repo where the official upstream lives elsewhere. There is usually a README.gcc explaining the rules of contributing, usually only very small bugfixes that are urgently needed are accepted temporarily into GCC without going to upstream first, otherwise people should go the upstream way and the fixes are either merged using full merges from upstream, or cherry-picked if they are needed faster. So, libffi after merging all the GCC improvements could be switched to similar mode. Jakub