This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Why not contribute? (to GCC)

On Sun, Apr 25, 2010 at 2:40 PM, Eric Botcazou <> wrote:
>> So we need more patch reviewers. ?How can that be addressed?
> The situation has improved in this area since the "Reviewer" position was
> introduced a few years ago though.
>> It is also important to make more effective use of the patch
>> reviewers we already have. ?What could be done to make the
>> patch review process easier or less time-consuming?
> Write small patches. ?Even if you know that the change is not a complete
> solution to the problem, it might be good enough as a first try so adding
> a ??? comment would be sufficient.
> Eliminate the easy mistakes in patches. ?GCC uses strict coding conventions,
> including formatting and commenting conventions, so not following them is a
> mistake that will be flagged as such. ?Fortunately this is easy to correct,
> 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 cannot
> be distinguished from the old one in this respect.
> Write proper ChangeLogs. ?They are kind of executive summaries for patches and
> help to grasp what they do. ?The various ChangeLog files have many examples.

Do not followup your patch with new versions every other day.  Doing so
sticks with reviewers and so you get ignored until they are confident
enough their review time is not wasted.

Thus, be confident of your own patches!  Have them tested _before_
submitting them (well, if you're not in the small group of people that
patch reviewers forgive when doing so).  Test your patches on a
common target (like i?86/x86_64-linux).


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]