This is the mail archive of the gcc@gcc.gnu.org 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]

Ad-hoc notes from the "pending patches" BOF at the GNU tools cauldron.


On a whim I hosted a BOF at the GNU tools cauldron yesterday,
titled "pending patches" (no compliance with RFC5434 intended).

This was originally only out of egotistic motives: BUMPing the
"Fix gcc.dg/lower-subreg-1.c failure, revisited" patch at
<http://gcc.gnu.org/ml/gcc-patches/2012-07/msg00280.html> (2
months from original) and "Ping again: [RFA:] Caveat for ARM in
gcc-4.7/changes.html: unaligned accesses, take 2" at
<http://gcc.gnu.org/ml/gcc-patches/2012-07/msg00282.html>, but I
also imagined there was a general need and opportunity to share
grief and maybe discuss patch handling a bit more off-the-record
than through the mailing-lists.

No pretense-silver-bullets were presented, but some of the ideas
that were aired seem worth pursuing.  I'm sure I don't remember
all good ideas (for one, I didn't actually take notes) and my
recollection might not match that of the consensus, so if you
were there (or if you were not) feel very free (as in software)
to follow-up.


Revive DannyB's patch tracker (deceased)?
No; (most) people actually reviewing patches didn't use it.

Automatic testing of submitted patches, with feedback?  Maybe;
might give added confidence in the patch, but not strictly a
patch-review issue.  Might be easier to implement for patches
entered in Bugzilla, where patches are more likely to have
machine-usable mark-up.

Volunteers making sure patches reach the right reviewer as
sometimes good patches aren't CCed to the right people?  This
might even be helped by a tool, somebody mentioned the Linux
scripts/get_maintainer.pl, with proper formatting of the
MAINTAINERS file (file globs to go with the domain of approval).
Also, volunteers (or more tools) to make sure that patches in
Bugzilla are also sent to the gcc-patches list.

More tools' suggestions to simplify patch handling: a tool or
archive-list function to find the archive entry for a certain
message-id.  I know this would help people writing pings.

There were also unspecified suggestions of improvements for
<http://gcc.gnu.org/contribute.html> but on revisiting that
page, I can't see anything I'd like to change ...except maybe
adding a call for volunteers for tasks not requiring paperwork,
for example patch follow-up as per above.  Oh, and instructions
on how to format ping messages to help speedy review;
specifically with the ChangeLog entry, a few lines explaining
the patch and archive URL to the original message.

More context (lines) in patches?  Not as a rule: people doing
review will look up the context anyway.  Mostly up to the patch
author to make any obviousness obvious.

Unfortunately no specific ideas on how to simplify reviewing for
approval-status reviewers, or how to get more reviewers, besides
of course that people are always welcome to comment on patches,
regardless of actual approver status.

brgds, H-P


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