Re: symlink-tree looks orphaned

Re: symlink-tree looks orphaned

[guerby]

> It seems your patches are changing files on the src side.  Such
> patches do not go to gcc-patches, they go to (well, this is the tricky
> part) binutils@sources.redhat.com, gdb-patches@sources.redhat.com,
> cygwin@cygwin.com, newlib@sources.redhat.com, and/or
> sid@sources.redhat.com, depending on the change you're proposing.
> Maybe the autoconf list also.  Maybe bug-gnu-utils@gcc.org too.

I looked at gdb, binutils and autoconf (CVS, www and mailing list
archives plus google), other projects look like unlikely source for
symlink-tree. I believe what the subject says "symlink-tree looks
orphaned", the last change made was made by you and only to the gcc
repository. I can send the email to all those lists if you want, but I
guess nobody will ever answer, and by definition nobody is responsible
for an orphaned file :).

So does the GCC project want to take care of symlink-tree? If so, it
has already the most up to date copy of it in CVS, and src is invited
to update its top-level MAINTAINERS file to reflect the news (you
looked like the guye knowing about MAINTAINERS for the src project),
and sync with the master copy in gcc (which is just applying my
patch).

-- 
Laurent Guerby <guerby@acm.org>

Re: symlink-tree looks orphaned

[DJ Delorie]

> I looked at gdb, binutils and autoconf (CVS, www and mailing list
> archives plus google), other projects look like unlikely source for
> symlink-tree. I believe what the subject says "symlink-tree looks
> orphaned", the last change made was made by you and only to the gcc
> repository. I can send the email to all those lists if you want, but I
> guess nobody will ever answer, and by definition nobody is responsible
> for an orphaned file :).
> 
> So does the GCC project want to take care of symlink-tree? If so, it
> has already the most up to date copy of it in CVS, and src is invited
> to update its top-level MAINTAINERS file to reflect the news (you
> looked like the guye knowing about MAINTAINERS for the src project),
> and sync with the master copy in gcc (which is just applying my
> patch).

Sorry, you misunderstood.  The change is on the src side, the patch
must be *sent* to the src side.  The GCC patch list is just not the
right place to post the patch, because the GCC project has nothing to
do with files in the src repository.  It's not even appropriate to
discuss who owns the file on the src side, unless you're discussing it
*on* the src side.

I suggest starting up a discussion on the binutils@sources.redhat.com
mailing list, for starters, for the changes that would happen on the
src side.