From: Christopher Faylor <cgf@redhat.com>
To: gdb@sources.redhat.com
Subject: [bangerth@ticam.utexas.edu: GCC review process: how to handle external submissions]
Date: Sat, 08 Mar 2003 20:21:00 -0000 [thread overview]
Message-ID: <20030308202134.GB32507@redhat.com> (raw)
Hmmmm.... Interesting thread over in the gcc list.
cgf
[NOTICE: Reply-To set because I don't want to read replies to this in my inbox]
----- Forwarded message from Wolfgang Bangerth <bangerth@ticam.utexas.edu> -----
From: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
To: gcc@gcc.gnu.org
Subject: GCC review process: how to handle external submissions
Date: Sat, 8 Mar 2003 00:40:09 -0600 (CST)
This week, I got three mails on the same subject, two of which read like
this:
> I submitted this to gcc-patches in November, resubmitted it in December,
> opened a bug report in January, wrote to gcc-bugs. I got no replies.
>
> I believe that this patch fixes a legitimate, reproducable bug and
> follows all patch submission guidelines on the gcc website.
>
> Please consider applying this patch. I would appreciate a reply in any
> case.
and
> The state of this is totally defunct.
> I have tried different request strategies for a few years
> and have concluded that only if I become a gcc insider
> can I get even the simplest changes made.
> I don't have the time, energy, or interest in that.
I get such mail about once every two weeks, when I ping people who
submitted PRs with patches about what happened to the patch. Gnats is full
of reports with patches in them.
I think we have a serious problem here. We are not only losing the
contributions from these people, we are also scaring them away, and I
don't think this is wise.
Can we at least discuss the reasons for this, and maybe come up with
suggestions about how we could improve this process? I think it would be
tremendously helpful if there were someone who
- could be contacted if there is a patch from somebody from outside gcc
- is willing to help with small problems like missing ChangeLog entries
or wrong formatting
- identifies port/front-end/... maintainer that would be qualified to
review the patch
- will take on some mediator function between patch submitter and
reviewer, if necessary
- most of all: takes care that patches are not silently dropped
I don't know whether this is reasonable, and even less if someone would
take over this position, but I think that in this respect our present
processes are inadequate.
As a final note: even if I say that we have many of these cases, they may
amount to 5-10 or so per month, and maybe 50-100 in gnats. Most of these
would probably be easy to review, if just someone cared -- the mail from
which I took the first quote contains everthing the patch submission
guidelines ask for, and did so back the first time it was submitted; the
patch is actually only two lines long; yet it was ignored 3 times.
Regards
Wolfgang
-------------------------------------------------------------------------
Wolfgang Bangerth email: bangerth@ticam.utexas.edu
----- End forwarded message -----
next reply other threads:[~2003-03-08 20:21 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-03-08 20:21 Christopher Faylor [this message]
2003-03-10 0:07 ` Jason Molenda
2003-03-10 5:58 ` Christopher Faylor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030308202134.GB32507@redhat.com \
--to=cgf@redhat.com \
--cc=gdb@sources.redhat.com \
--cc=gdb@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox