[bangerth@ticam.utexas.edu: GCC review process: how to handle external submissions]

[bangerth@ticam.utexas.edu: GCC review process: how to handle external submissions]

[Christopher Faylor]

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 -----

Re: [bangerth@ticam.utexas.edu: GCC review process: how to handle external submissions]

[Jason Molenda]

> 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)
>
>
> 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


And to further demonstrate that we're all discussing the same problem 
at the same time, this came up on the subversion-dev list last week.  
Their approach is to have humans do it by hand.  cf

	http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=32389

It's an interesting approach -- it takes advantage of the idea that 
there are many volunteers interested in helping a project but aren't 
hacker gods.  On the other hand, it assumes that the volunteer won't 
disappear or let things drop on the floor if he runs short on time...

J

Re: [bangerth@ticam.utexas.edu: GCC review process: how to handle external submissions]

[Christopher Faylor]

On Sun, Mar 09, 2003 at 04:05:59PM -0800, Jason Molenda wrote:
>>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)
>>
>>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
>
>And to further demonstrate that we're all discussing the same problem
>at the same time, this came up on the subversion-dev list last week.
>Their approach is to have humans do it by hand.  cf
>
>http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=32389
>
>It's an interesting approach -- it takes advantage of the idea that
>there are many volunteers interested in helping a project but aren't
>hacker gods.  On the other hand, it assumes that the volunteer won't
>disappear or let things drop on the floor if he runs short on time...

We use what sounds like a similar process over in cygwin-land to handle
things like package submissions.  We have a package submission tracker
who keeps track of who's submitted what and what state it's in.  We have
someone who keeps track of patches for the cygwin setup utility also.

Patches for cygwin itself stay in my inbox until they are reviewed.
Hmm.  Where did I hear about someone using a similar scheme somewhere?

I wonder if there is anyone in gdb-land who would be willing to be a
patch tracker and maybe operate as a polite nagger for unreviewed
patches.  It seems to work pretty well for cygwin.

cgf