* Re: Unreviewed patch [not found] <200306121332.h5CDWGJ10519@r-rr.iij4u.or.jp> @ 2003-06-12 14:42 ` Tom Tromey 2003-06-12 15:22 ` Anthony Green 2003-06-12 23:19 ` kaz Kojima [not found] ` <3EE89AEE.452EC932@superh.com> 1 sibling, 2 replies; 6+ messages in thread From: Tom Tromey @ 2003-06-12 14:42 UTC (permalink / raw) To: kaz Kojima; +Cc: gcc-patches, java, joern.rennecke, aoliva, GCC Hackers >>>>> "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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Unreviewed patch 2003-06-12 14:42 ` Unreviewed patch Tom Tromey @ 2003-06-12 15:22 ` Anthony Green 2003-06-12 16:09 ` Joseph S. Myers 2003-06-12 23:19 ` kaz Kojima 1 sibling, 1 reply; 6+ messages in thread From: Anthony Green @ 2003-06-12 15:22 UTC (permalink / raw) To: tromey Cc: kaz Kojima, gcc-patches, java, joern.rennecke, Alexandre Oliva, GCC Hackers 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Unreviewed patch 2003-06-12 15:22 ` Anthony Green @ 2003-06-12 16:09 ` Joseph S. Myers 0 siblings, 0 replies; 6+ messages in thread From: Joseph S. Myers @ 2003-06-12 16:09 UTC (permalink / raw) To: Anthony Green Cc: tromey, kaz Kojima, gcc-patches, java, joern.rennecke, Alexandre Oliva, GCC Hackers 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Unreviewed patch 2003-06-12 14:42 ` Unreviewed patch Tom Tromey 2003-06-12 15:22 ` Anthony Green @ 2003-06-12 23:19 ` kaz Kojima 1 sibling, 0 replies; 6+ messages in thread From: kaz Kojima @ 2003-06-12 23:19 UTC (permalink / raw) To: tromey; +Cc: green, gcc-patches, java, joern.rennecke, aoliva, gcc 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <3EE89AEE.452EC932@superh.com>]
* Re: Unreviewed patch [not found] ` <3EE89AEE.452EC932@superh.com> @ 2003-06-12 15:47 ` Gerald Pfeifer 0 siblings, 0 replies; 6+ messages in thread From: Gerald Pfeifer @ 2003-06-12 15:47 UTC (permalink / raw) To: Anthony Green, Joern Rennecke Cc: tromey, kaz Kojima, gcc-patches, java, Alexandre Oliva, GCC Hackers 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/ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Unreviewed patch @ 2002-07-25 7:34 Momchil Velikov 0 siblings, 0 replies; 6+ messages in thread From: Momchil Velikov @ 2002-07-25 7:34 UTC (permalink / raw) To: gcc; +Cc: joern.rennecke HEAD fails to build for ``sh-elf'' target. http://gcc.gnu.org/ml/gcc-patches/2002-07/msg00433.html ~velco ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2003-06-12 23:11 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <200306121332.h5CDWGJ10519@r-rr.iij4u.or.jp> 2003-06-12 14:42 ` Unreviewed patch Tom Tromey 2003-06-12 15:22 ` Anthony Green 2003-06-12 16:09 ` Joseph S. Myers 2003-06-12 23:19 ` kaz Kojima [not found] ` <3EE89AEE.452EC932@superh.com> 2003-06-12 15:47 ` Gerald Pfeifer 2002-07-25 7:34 Momchil Velikov
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).