From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26983 invoked by alias); 25 Apr 2010 13:05:56 -0000 Received: (qmail 26972 invoked by uid 22791); 25 Apr 2010 13:05:55 -0000 X-SWARE-Spam-Status: No, hits=0.8 required=5.0 tests=BAYES_20,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SARE_MSGID_LONG45 X-Spam-Check-By: sourceware.org Received: from mail-qy0-f199.google.com (HELO mail-qy0-f199.google.com) (209.85.221.199) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 25 Apr 2010 13:05:49 +0000 Received: by qyk37 with SMTP id 37so7800112qyk.8 for ; Sun, 25 Apr 2010 06:05:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.65.132 with SMTP id j4mr750300qai.315.1272200745918; Sun, 25 Apr 2010 06:05:45 -0700 (PDT) Received: by 10.224.11.84 with HTTP; Sun, 25 Apr 2010 06:05:45 -0700 (PDT) In-Reply-To: <11004251300.AA01142@vlsi1.ultra.nyu.edu> References: <4BD36245.30501@andihellmund.com> <4BD36544.6090702@oarcorp.com> <201004251440.32761.ebotcazou@adacore.com> <11004251300.AA01142@vlsi1.ultra.nyu.edu> Date: Sun, 25 Apr 2010 13:10:00 -0000 Message-ID: Subject: Re: Why not contribute? (to GCC) From: Steven Bosscher To: Richard Kenner Cc: ebotcazou@adacore.com, gcc@gcc.gnu.org, joel.sherrill@oarcorp.com, lopezibanez@gmail.com, mail@andihellmund.com, richard.guenther@gmail.com, tneumann@users.sourceforge.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2010-04/txt/msg00699.txt.bz2 On Sun, Apr 25, 2010 at 3:00 PM, Richard Kenner wrote: >> Eliminate the easy mistakes in patches. =A0GCC uses strict coding conven= tions, >> including formatting and commenting conventions, so not following them i= s a >> mistake that will be flagged as such. =A0Fortunately this is easy to cor= rect, >> you don't even need to read the (whole) documentation, just look around = in >> the existing code you're modifying and make it so that the new code cann= ot >> be distinguished from the old one in this respect. >> >> Write proper ChangeLogs. =A0They are kind of executive summaries for pat= ches >> and help to grasp what they do. =A0The various ChangeLog files have many >> examples. > > Moreover, I think that having a patch that's improperly formatted or > missing or improper ChangeLog may simply cause reviewers to ignore the > patch because they don't want to have to deal with explaining these > things to people. =A0This SHOULDN'T happen, but I'm pretty sure it does. In the aerospace industry we have a somewhat similar problem. Every part of assembly drawing has to be reviewed ("checked") and approved. But the common mistakes often are so distracting that checkers don't even want to begin to comment on to-be-released drawing in the PDM system. It is very demotivating to review something and you're just pointing out issues with formalities instead of focusing on the actual design. The solution for this in my working environment is an automatic checker. This checker validates the drawing against a set of requirements (proper design principles, proper drawing formatting, correct label, etc.). You can't upload a drawing for check in the PDM system until it passes the checker (it is part of the PDM system, and it simply rejects drawings that don't pass). Perhaps it is possible to create some kind of check-patch script for GCC too, e.g. one that checks the following things at least: * ChangeLog presence * ChangeLog format and completeness * formatting / coding style of the patch itself We should perhaps make tools available in contrib/ that help people set up things properly for patch submission. For example Diego had a script that extracts a skeleton ChangeLog from a patch, perhaps it should be put in contrib/ and advertised somewhere (e.g. wiki). There are many things beside this that we could do to simplify the patch submission process. It's just part of the problem but perhaps it helps. Ciao! Steven