GCC review process: how to handle external submissions

GCC review process: how to handle external submissions

[Wolfgang Bangerth]

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
                              www: http://www.ticam.utexas.edu/~bangerth/

Re: GCC review process: how to handle external submissions

[Craig Rodrigues]

On Sat, Mar 08, 2003 at 12:40:09AM -0600, Wolfgang Bangerth wrote:
> 
> 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.

This has been a problem for quite a while.
I have the following recommendations once Bugzilla is fully set up:

- eliminate the gcc-gnats mailing list (keep around the archives)
- send all new entries and followups entered in Bugzilla to gcc-bugs

I notice that people enter reports and sometimes patches in GNATS,
but few people read gcc-gnats.

There are too many mailing lists to follow, i.e. gcc-gnats, gcc-patches,
gcc-bugs, so sometimes patches submitted by end-users fall through
the cracks.

My recommendation won't solve all the problems, but it is an
idea to consolidate some lists to make things easier to follow.
-- 
Craig Rodrigues        
http://home.attbi.com/~rodrigc
rodrigc@attbi.com

Re: GCC review process: how to handle external submissions

[Joseph S. Myers]

On Sat, 8 Mar 2003, Craig Rodrigues wrote:

> - eliminate the gcc-gnats mailing list (keep around the archives)

gcc-gnats is not a mailing list, it is the address on which GNATS receives
and files new bug reports, follow-ups and spam.  With Bugzilla it will
have a converter to receive gccbug format input and PR follow-ups and file
them in Bugzilla (but not, I hope, continue to file spam as "pending" bug
reports).

gcc-prs is the mailing list that ought to be eliminated.

> - send all new entries and followups entered in Bugzilla to gcc-bugs

Yes.  Ideally (to avoid lots of duplication of messages on gcc-bugs), the 
messages should have the Bugzilla address for receiving follow-ups and 
filing them in their headers, but should not mention gcc-bugs in their 
headers (and gcc-bugs's spam protection should be set up to understand 
this).  But duplication is better than the follow-ups being hidden (at 
present, if someone doesn't CC their follow-up to gcc-bugs, but only sends 
it to gcc-gnats, it only appears on gcc-prs, which few read).

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: GCC review process: how to handle external submissions

[Craig Rodrigues]

On Sat, Mar 08, 2003 at 07:00:36PM +0000, Joseph S. Myers wrote:
> gcc-gnats is not a mailing list, it is the address on which GNATS receives

OK.  Maybe a gcc-bugzilla alias to gcc-gnats should be created 
at some point (this is not critical) to preserve backwards compatibility, 
but more accurately reflect what software is being used?

> Yes.  Ideally (to avoid lots of duplication of messages on gcc-bugs), the 
> messages should have the Bugzilla address for receiving follow-ups and 
> filing them in their headers, but should not mention gcc-bugs in their 
> headers (and gcc-bugs's spam protection should be set up to understand 
> this).  But duplication is better than the follow-ups being hidden (at 
> present, if someone doesn't CC their follow-up to gcc-bugs, but only sends 
> it to gcc-gnats, it only appears on gcc-prs, which few read).

I agree with you and I think I have seen Red Hat's Bugzilla setup
do what you ask.  
They set the mail headers something like:

 Return-Path: <bugzilla@redhat.com>
 From: bugzilla@redhat.com
 To: notting@redhat.com, rodrigc@mediaone.net
 Subject: [Bug 6219] Changed - /etc/protocols is missing entries for IPv6
 X-Mailer: Perl SMTP Module
 X-Loop: bugzilla@redhat.com
 X-Keywords:


If you reply to that message, it will go to bugzilla@redhat.com.

So if something code be set up so that replying to a message
from gcc-gnats@gcc.gnu.org (or gcc-bugzilla@gcc.gnu.org) will:
  (1)  Have the From and Return-Path headers contain 
       gcc-gnats@gcc.gnu.org (or gcc-bugzilla@gcc.gnu.org)
  (2)  Put the e-mails of all the addresses registered in the PR
       in the To: field.
  (3)  Also send the e-mail to gcc-bugs@gcc.gnu.org (or gcc-bugzilla)

That way, if a user replies to such a message, it will be sent
archived in Bugzilla *and* sent to gcc-bugs.

I think that would be nice.
-- 
Craig Rodrigues        
http://home.attbi.com/~rodrigc
rodrigc@attbi.com

Re: GCC review process: how to handle external submissions

[Geoff Keating]

Craig Rodrigues <rodrigc@attbi.com> writes:

> There are too many mailing lists to follow, i.e. gcc-gnats, gcc-patches,
> gcc-bugs, so sometimes patches submitted by end-users fall through
> the cracks.

For patches, there's only one mailing list, gcc-patches.  It'd be
helpful if anyone noticing patches being sent elsewhere could reply to
the submitter asking for the patch to be sent to gcc-patches.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: GCC review process: how to handle external submissions

[Neil Booth]

Joseph S. Myers wrote:-

> > - eliminate the gcc-gnats mailing list (keep around the archives)
> 
> gcc-gnats is not a mailing list, it is the address on which GNATS receives
> and files new bug reports, follow-ups and spam.

Wow, it's intended to receive spam?  8-)

Neil.

Re: GCC review process: how to handle external submissions

[Laurent Guerby]

On Sat, 2003-03-08 at 21:29, Geoff Keating wrote:
> Craig Rodrigues <rodrigc@attbi.com> writes:
> 
> > There are too many mailing lists to follow, i.e. gcc-gnats, gcc-patches,
> > gcc-bugs, so sometimes patches submitted by end-users fall through
> > the cracks.
> 
> For patches, there's only one mailing list, gcc-patches.  It'd be
> helpful if anyone noticing patches being sent elsewhere could reply to
> the submitter asking for the patch to be sent to gcc-patches.

May be there should be a "with patch" checkbox that triggers
that behaviour in bugzilla (if not already there... bugzilla's magic :).

-- 
Laurent Guerby <guerby@acm.org>

Re: GCC review process: how to handle external submissions

[Wolfgang Bangerth]

> > > 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.
> 
> This has been a problem for quite a while.
> [...]
> There are too many mailing lists to follow, i.e. gcc-gnats, gcc-patches,
> gcc-bugs, so sometimes patches submitted by end-users fall through
> the cracks.

This is not the structural problem we should talk about. Note that this 
person sent a patch to *gcc-patches* three times without response. This 
applies to at least several of the patches in gnats as well. Heck, I have 
done that myself and got no response.

The problem is not that these messages are not seen -- I bet they are, but 
nobody feels responsible. We need to have someone with a respected name 
(so that he can ask reviewers to look at something) who takes over this 
responsibility.

W.

-------------------------------------------------------------------------
Wolfgang Bangerth             email:            bangerth@ticam.utexas.edu
                              www: http://www.ticam.utexas.edu/~bangerth/

Re: GCC review process: how to handle external submissions

[Steven Bosscher]

Op ma 10-03-2003, om 15:45 schreef Wolfgang Bangerth:
> 
> > > > 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.
> > 
> > This has been a problem for quite a while.
> > [...]
> > There are too many mailing lists to follow, i.e. gcc-gnats, gcc-patches,
> > gcc-bugs, so sometimes patches submitted by end-users fall through
> > the cracks.
> 
> This is not the structural problem we should talk about. Note that this 
> person sent a patch to *gcc-patches* three times without response. This 
> applies to at least several of the patches in gnats as well. Heck, I have 
> done that myself and got no response.

Does bugzilla provide an option to mark PRs that have a patch?

> The problem is not that these messages are not seen -- I bet they are, but 
> nobody feels responsible. We need to have someone with a respected name 
> (so that he can ask reviewers to look at something) who takes over this 
> responsibility.

Maybe a patch database would help?  This could be part of the bug
database, or something completely separate.  gcc-patches is too much a
discussions list to serve as a patch database.

Greetz
Steven

Re: GCC review process: how to handle external submissions

[Daniel Berlin]

On Saturday, March 8, 2003, at 02:00  PM, Joseph S. Myers wrote:

> On Sat, 8 Mar 2003, Craig Rodrigues wrote:
>
>> - eliminate the gcc-gnats mailing list (keep around the archives)
>
> gcc-gnats is not a mailing list, it is the address on which GNATS 
> receives
> and files new bug reports, follow-ups and spam.  With Bugzilla it will
> have a converter to receive gccbug format input and PR follow-ups and 
> file
> them in Bugzilla (but not, I hope, continue to file spam as "pending" 
> bug
> reports).

They won't be valid GNATS input, so it won't file them.
I've tried.
:)

>
> gcc-prs is the mailing list that ought to be eliminated.
>
>> - send all new entries and followups entered in Bugzilla to gcc-bugs
>
> Yes.  Ideally (to avoid lots of duplication of messages on gcc-bugs), 
> the
> messages should have the Bugzilla address for receiving follow-ups and
> filing them in their headers, but should not mention gcc-bugs in their
> headers (and gcc-bugs's spam protection should be set up to understand
> this).

I'm a little unclear on what exactly you guys want (IE by "Bugzilla 
address" do you mean seperate addresses for each bug or what) , but if 
you hash it out and let me know, i should be able to make it happen.

>  But duplication is better than the follow-ups being hidden (at
> present, if someone doesn't CC their follow-up to gcc-bugs, but only 
> sends
> it to gcc-gnats, it only appears on gcc-prs, which few read).
>

> -- 
> Joseph S. Myers
> jsm28@cam.ac.uk
>

Re: GCC review process: how to handle external submissions

[Craig Rodrigues]

On Tue, Mar 11, 2003 at 06:29:02PM -0500, Daniel Berlin wrote:
> I'm a little unclear on what exactly you guys want (IE by "Bugzilla 
> address" do you mean seperate addresses for each bug or what) , but if 
> you hash it out and let me know, i should be able to make it happen.

If I subscribe to gcc-bugs@gcc.gnu.org, I should see messages generated
by Bugzilla with the following headers:

 Return-Path: <gcc-bugzilla@gcc.gnu.org>
 From: gcc-bugzilla@gcc.gnu.org
 To: user1@someplace, user2@someplace
 Date: some date
 Subject: [Bug 4835] bug subject line
 Message-Id: <some message ID>


If I reply this message, the following should happen:
   -> the database entry for bug 4835 will get updated with my reply
   -> all e-mail addresses which are registered in the Bugzilla database
      for bug 4835 will get copies of this reply.  These e-mail addresses
      ( user1@someplace, user2@someplace) will appear in the To: field
   -> Bugzilla will magically send a copy of this message
      to gcc-bugs@gcc.gnu.org, but gcc-bugs@gcc.gnu.org will not appear
      anywhere in the e-mail header.  That way, if I reply to this message,
      it will go to gcc-bugzilla.


Does this make sense?

Thanks.
-- 
Craig Rodrigues        
http://home.attbi.com/~rodrigc
rodrigc@attbi.com

Re: GCC review process: how to handle external submissions

[Daniel Berlin]

On Monday, March 10, 2003, at 10:14  AM, Steven Bosscher wrote:

> Op ma 10-03-2003, om 15:45 schreef Wolfgang Bangerth:
>>
>>>>> 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.
>>>
>>> This has been a problem for quite a while.
>>> [...]
>>> There are too many mailing lists to follow, i.e. gcc-gnats, 
>>> gcc-patches,
>>> gcc-bugs, so sometimes patches submitted by end-users fall through
>>> the cracks.
>>
>> This is not the structural problem we should talk about. Note that 
>> this
>> person sent a patch to *gcc-patches* three times without response. 
>> This
>> applies to at least several of the patches in gnats as well. Heck, I 
>> have
>> done that myself and got no response.
>
> Does bugzilla provide an option to mark PRs that have a patch?
>
You can mark individual attachments as being a patch, and it will 
notice.

In fact, i'm about to integrate a cool patch viewer that will does
1. Viewing of patches in a pretty way
2. Ability to convert context to unified/etc
3. Attempt to provide diffs from a patch to a given cvs version
4.  interdiffs on patches that are attached to bugs, so you can see the 
differences between them (since you can supersede/obsolete attachments, 
this is useful if you use bugs to track patches).
and a few other things

>> The problem is not that these messages are not seen -- I bet they 
>> are, but
>> nobody feels responsible. We need to have someone with a respected 
>> name
>> (so that he can ask reviewers to look at something) who takes over 
>> this
>> responsibility.
>
> Maybe a patch database would help?  This could be part of the bug
> database, or something completely separate.  gcc-patches is too much a
> discussions list to serve as a patch database.
>
Bugzilla lets you add user-defined flags to bugs/attachments, including 
having a cc list to whom requests get copied, and making it so you can 
request someone else set the flag.
So one can have a review flag on attachments that people use to request 
review on patches from specific people (or anyone, if it's a general 
patch, and not within some specific person's area).
Requests for setting flags on attachments/bugs are what show up in the 
"My requests" thing.
> Greetz
> Steven
>
>

Re: GCC review process: how to handle external submissions

[Daniel Berlin]

On Tuesday, March 11, 2003, at 06:52  PM, Craig Rodrigues wrote:

> On Tue, Mar 11, 2003 at 06:29:02PM -0500, Daniel Berlin wrote:
>> I'm a little unclear on what exactly you guys want (IE by "Bugzilla
>> address" do you mean seperate addresses for each bug or what) , but if
>> you hash it out and let me know, i should be able to make it happen.
>
> If I subscribe to gcc-bugs@gcc.gnu.org, I should see messages generated
> by Bugzilla with the following headers:
>
>  Return-Path: <gcc-bugzilla@gcc.gnu.org>
>  From: gcc-bugzilla@gcc.gnu.org
>  To: user1@someplace, user2@someplace
>  Date: some date
>  Subject: [Bug 4835] bug subject line
>  Message-Id: <some message ID>
>
>
> If I reply this message, the following should happen:
>    -> the database entry for bug 4835 will get updated with my reply
This will happen

>    -> all e-mail addresses which are registered in the Bugzilla 
> database
>       for bug 4835 will get copies of this reply.  These e-mail 
> addresses
>       ( user1@someplace, user2@someplace) will appear in the To: field
>
This will happen because the comments will have changed, and it will 
send bug changed mail.

>    -> Bugzilla will magically send a copy of this message
>       to gcc-bugs@gcc.gnu.org, but gcc-bugs@gcc.gnu.org will not appear
>       anywhere in the e-mail header.  That way, if I reply to this 
> message,
>       it will go to gcc-bugzilla.
>
I'll make it bcc bug changes to gcc-bugs.

>
> Does this make sense?
>
Yup.

> Thanks.
> -- 
> Craig Rodrigues
> http://home.attbi.com/~rodrigc
> rodrigc@attbi.com

Re: GCC review process: how to handle external submissions

[Gerald Pfeifer]

[ Three suggestions at the end, which everybody might want to check. ]

On Sat, 8 Mar 2003, Wolfgang Bangerth wrote:
> 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.

This is mighty unfortunate, and (as a sporadic contributor to other
projects) I can understand the enormous frustration this may cause.

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

We also have another serious problem here: Nobody had anything to respond
to your message for more than two weeks.  Us being a volunteer project,
I can understand all that, but still, we are having a serious problem here.

> 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

Fully agreed; in most cases identifying a suitable maintainer and pinging
him should be sufficient.

Other approaches I have in mind:

A) Patches that have been submitted at least twice without being properly
   dealt with shall submitted to GNATS/Bugzilla, and as part of our
   release process we guarantee to deal with all such patches submitted
   before a specific cut-off date (say, the beginning of phase 3).

B) We need further maintainers. This is something where we have made
   progress, but if you'd like to suggest anybody qualified as maintainer
   for any part of GCC (including "upgrades" of existing maintainers)
   please suggest that to your SC member of choice!

C) We might consider allowing two contributors with experience in some
   area which they do not (yet) maintain officially to approve patches
   together.

Gerald
-- 
Gerald "Jerry"   pfeifer@dbai.tuwien.ac.at   http://www.pfeifer.com/gerald/