This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: (ti)c4x maintainer
Jim Wilson wrote:
It isn't ideal, but it is acceptable. After all, a GCC maintainer is a
volunteer, and there is no requirement that they perform any
particular task.
If a volunteer isn't serving our needs, then we can consider adding a
co-maintainer or asking for a resignation. But there shouldn't be any
need
to take action against someone just because mail wasn't answered for a
month.
And my intentions was not to throw somebody out either; I have
absolutely no interest in making this maintainer "banned". It serves no
good to do so! He is a good friend has done a great job in the c4x target!
But, as I have spent loads of time fixing binutils, and when I'm finally
done, I think its a bit stupid that I cannot get these two very small
patches committed to gcc because of some trivial reason like this. Thats
it. No hard feelings. The effect of it in sum will be that the
users/customers/community will notice this delay (by missing a release,
for instance). *I* can always run my own patches on my own computer and
release them on my web-page...
So my suggestion to the case was simply to make me a co-maintainer so
that I can fix the most obvious bugs as I encounter them while testing,
but still keep the main responsibilty on Michael. The sole reason for
not wanting to take the full (co-)maintainer responsibility is because I
dont know the impacts of being one - and I'm overloaded with work
already. I do not know the internals gcc well enough (yet - I'm learning).
The other option was to make someone else approve and apply them, but I
dont know whose chain to rattle. Even despite the fact that the patch
was sent to the gcc-patches list, does not guarantee that someone other
than the maintainer picks it up. An example is the patch that is
approved medio. october but not applied.
By the way, these kinds of problems are why it is a good idea to send
patches
to the list instead of to a specific maintainer. There are a number
of people
who can approve c4x patches. So there is no need for c4x development
to stop
just because the c4x maintainer is at the moment not answering mail.
I have always sent them to the gcc-patches maillist...
Svein