libffi maintenance

libffi maintenance

[Anthony Green]

Here's a quick update on libffi maintenance going forward.

I've moved the libffi repo to a new 'project' on github.  The bits are
now located at https://github.com/libffi.

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're also long overdue for a new release.  I'd like to assess the
patch backlog in about a month before deciding what to do.

Thanks!

AG

Re: libffi maintenance

[Andrew Haley]

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.

Andrew.

Re: libffi maintenance

[Jakub Jelinek]

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

Re: libffi maintenance

[Richard Henderson]

On 05/02/2016 09:41 PM, 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.

Indeed.  But in causing gccgo to use libffi, I needed to make extensions to 
libffi (ffi_call_go etc).  The two repos were synced at that time, modulo the 
configure stuff.


r~