Re: Unreviewed patch

Re: Unreviewed patch

[Tom Tromey]

>>>>> "kaz" == kaz Kojima <kkojima@rr.iij4u.or.jp> writes:

kaz> libffi sh64-*-linux* support:
kaz> <URL:http://gcc.gnu.org/ml/gcc-patches/2003-05/msg02321.html>

As you've discovered, libffi is a bit under maintained.  I'm not
really the person to do it -- I'd do little more than rubber stamp
patches that come in.  I'm happy to do that, though, in the absence of
a better process.  Hopefully some more qualified person out there will
speak up (and we'll end up with a libffi entry in MAINTAINERS).

I believe we've agreed in the past that port maintainers can make
port-specific libffi changes.  So I think you can check in your fix on
that basis.

Tom

Re: Unreviewed patch

[Anthony Green]

On Thu, 2003-06-12 at 07:15, Tom Tromey wrote:
>  Hopefully some more qualified person out there will
> speak up (and we'll end up with a libffi entry in MAINTAINERS).
> 
> I believe we've agreed in the past that port maintainers can make
> port-specific libffi changes.  So I think you can check in your fix on
> that basis.

The situation is a little frustrating because it's not made explicit in
the MAINTAINERS file.  I once tried to clear this up with the SC through
one of its members, but got no reply.

My suggestion is that the following people should be able to approve
libffi changes:

0. Global maintainers
1. GCC port maintainers, since many times they will be the only ones who
understand the asm code.
2. Tromey, as the maintainer of libgcj, since this is an important part
of it.
3. Me, as the original author.

BTW - I think we should also add MAINTAINERS entries for zlib, boehm-gc
and fastjar.

AG

-- 
Anthony Green <green@redhat.com>
Red Hat, Inc.

Re: Unreviewed patch

[Gerald Pfeifer]

On Thu, 12 Jun 2003, Anthony Green wrote:
>> I believe we've agreed in the past that port maintainers can make
>> port-specific libffi changes.  So I think you can check in your fix
>> that basis.
> The situation is a little frustrating because it's not made explicit in
> the MAINTAINERS file.  I once tried to clear this up with the SC through
> one of its members, but got no reply.

That's unfortunate.

> My suggestion is that the following people should be able to approve
> libffi changes:
>
> 0. Global maintainers
> 1. GCC port maintainers, since many times they will be the only ones who
> understand the asm code.
> 2. Tromey, as the maintainer of libgcj, since this is an important part
> of it.
> 3. Me, as the original author.
> BTW - I think we should also add MAINTAINERS entries for zlib, boehm-gc
> and fastjar.

Would you mind suggesting appropriate additions to the MAINTAINERS file?
I'll happily forward them to the SC and make sure to follow it.

On Thu, 12 Jun 2003, Joern Rennecke wrote:
> I'm somewhat unsure about the status of libffi.  On the one
> hand it is a separate project, and as such it appears that only
> Anthony Green can approve patches.
> On the other hand the libffi home page says 'libffi is now largely
> maintained as part of GCC.' , and if it is actually maintained as
> part of GCC, that would mean that global and target port maintainers
> of gcc can approve patches.

The point is, is it largely maintained as part of GCC, or is it now
part of GCC (like, for example, libstdc++ and libgcj which became
fully integrated)?

Gerald
-- 
Gerald "Jerry"   pfeifer@dbai.tuwien.ac.at   http://www.pfeifer.com/gerald/

Re: Unreviewed patch

[Joseph S. Myers]

On Thu, 12 Jun 2003, Anthony Green wrote:

> > I believe we've agreed in the past that port maintainers can make
> > port-specific libffi changes.  So I think you can check in your fix on
> > that basis.
> 
> The situation is a little frustrating because it's not made explicit in
> the MAINTAINERS file.  I once tried to clear this up with the SC through
> one of its members, but got no reply.

cvswrite.html currently says:

          Maintainers of a port maintain the files in config/port/, the
          configure fragments for the port, documentation for the port
          and test cases for features or bugs specific to this port. Port
          maintainers do not have approval rights in other files.

Perhaps this should be expanded to list target-specific files outside the
gcc directory.  In that case, the FIXME in sourcebuild.texi asking for a
list of such places, in the checklist of what's needed in a target port,
could be filled in at the same time.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Unreviewed patch

[kaz Kojima]

Tom Tromey <tromey@redhat.com> wrote:
> As you've discovered, libffi is a bit under maintained.  I'm not
> really the person to do it -- I'd do little more than rubber stamp
> patches that come in.  I'm happy to do that, though, in the absence of
> a better process.  Hopefully some more qualified person out there will
> speak up (and we'll end up with a libffi entry in MAINTAINERS).
> 
> I believe we've agreed in the past that port maintainers can make
> port-specific libffi changes.  So I think you can check in your fix on
> that basis.

I'd like to check my patch in. Thanks.

I totally agree with your and Anthony's suggestion about the approvement 
for libffi changes, though in this specific case I hesitate over because
sh64-linux is for the SHmedia processor with a new and very different ISA
from the other SH family and I'm rather new to SHmedia.
So I thought and still think that it would be nice if SHmedia experts see
my patch.

BTW, libjava works to some extent with the sjlj configuration using this
libffi port. I'll report it to the java list.

Regards,
	kaz

Unreviewed patch

[Momchil Velikov]

HEAD fails to build for ``sh-elf'' target.
http://gcc.gnu.org/ml/gcc-patches/2002-07/msg00433.html

~velco