Non-gcc releases

[Tom Tromey <tromey at redhat dot com>]

Etienne recently brought up the idea of changing libffi maintenance
and/or releases so that it isn't tied to the GCC release schedule.

I think we can do this, it just requires someone willing to do the
work.  It may also require a little bit of buy-in from the GCC SC, I'm
not sure.

Some issues:

- libffi is in a strange state regarding copyright assignment.  We're
  in the middle of a complicated process to get everything assigned
  to the FSF.  I think any major new contributors have to be willing
  to sign papers at some point in the future (unfortunately I think
  the FSF won't accept paperwork until the existing code has been
  assigned, complicating everything)

  We'd probably need FSF paperwork to get anybody new write access to
  the gcc repository at all.

  The license won't change as a result of this.  So no worries there.

- The gcc tree has rules about when it is or is not acceptable to
  make certain sorts of changes.  This could interfere with whatever
  release schedule we come up with for libffi.

  This is easy enough to work around by making branches for libffi
  work when that work conflicts with gcc.  We'll want to make release
  branches anyway, since we'll want to give libffi its own version
  numbers.

- Perhaps we should at least get approval from the SC to use the tree
  for this sort of thing?

Etienne and I also discussed moving libffi out of the gcc tree and
into its own repository somewhere.  I'd prefer not to do this.  My
impression was that Etienne could find someone to do releases and that
sort of thing, but that doing actual libffi maintenance was too much
work.  One nice advantage of keeping the code in the gcc tree is that
there are many platform and ABI experts around, so we can run the
various bits of assembly code past them for approval.  I think getting
this sort of review out-of-tree would be much more difficult.

Anything else?

If you know someone who is interested in this discussion, by all means
have them subscribe here and take part.  Ideally we'd get all the
libffi users together to make decisions.  Until now we've pretty much
made decisions unilaterally for libgcj's benefit, but we can and
should change this to include anyone interested in the project.

Tom