public inbox for libffi-discuss@sourceware.org
 help / color / mirror / Atom feed
* libffi maintenance
@ 2016-05-02 13:51 Anthony Green
  2016-05-03  7:41 ` Andrew Haley
  0 siblings, 1 reply; 4+ messages in thread
From: Anthony Green @ 2016-05-02 13:51 UTC (permalink / raw)
  To: libffi-discuss

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: libffi maintenance
  2016-05-02 13:51 libffi maintenance Anthony Green
@ 2016-05-03  7:41 ` Andrew Haley
  2016-05-03  7:50   ` Jakub Jelinek
  2016-05-03 14:39   ` Richard Henderson
  0 siblings, 2 replies; 4+ messages in thread
From: Andrew Haley @ 2016-05-03  7:41 UTC (permalink / raw)
  To: Anthony Green, libffi-discuss

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.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: libffi maintenance
  2016-05-03  7:41 ` Andrew Haley
@ 2016-05-03  7:50   ` Jakub Jelinek
  2016-05-03 14:39   ` Richard Henderson
  1 sibling, 0 replies; 4+ messages in thread
From: Jakub Jelinek @ 2016-05-03  7:50 UTC (permalink / raw)
  To: Andrew Haley; +Cc: Anthony Green, libffi-discuss

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: libffi maintenance
  2016-05-03  7:41 ` Andrew Haley
  2016-05-03  7:50   ` Jakub Jelinek
@ 2016-05-03 14:39   ` Richard Henderson
  1 sibling, 0 replies; 4+ messages in thread
From: Richard Henderson @ 2016-05-03 14:39 UTC (permalink / raw)
  To: Andrew Haley, Anthony Green, libffi-discuss

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~

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2016-05-03 14:39 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-05-02 13:51 libffi maintenance Anthony Green
2016-05-03  7:41 ` Andrew Haley
2016-05-03  7:50   ` Jakub Jelinek
2016-05-03 14:39   ` Richard Henderson

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).