Re: patch tracking

["Joseph S. Myers" <jsm28@cam.ac.uk>]

On Fri, 14 Sep 2001, Joe Buck wrote:

> First, we want to decrease the number of patches that the overworked
> experts must handle, by having a pre-screening process.  So, we have
> a team of volunteers who have some experience but are not necessarily
> gurus.  These folks would be the first screen for incoming patches.  They
> would ask the following questions:

We *really* need this for bugs as well.  Volunteers for bug checking don't
need great expertise (though they do need some familiarity with common
pitfalls of the programming language): they should

	* Check that all relevant information about version, target, etc., 
	is included.  If enough information to reproduce isn't present, 
	put the report in feedback state.

	* Test the bug against the current release *and* mainline CVS, if 
	possible on the same target.  (Also using -Wall to detect possible 
	bugs in the code, etc..)  If the bug report is a --enable-checking 
	one, make sure they don't just check against a release with 
	enable-checking turned off.  If the bug report claims that a 
	release branch fix (2.95 or 3.0) is warranted, e.g. because of a 
	regression, don't automatically close it because a fix is on the 
	mainline.

	* If the bug is no longer present, close as fixed; if present and
	seems valid, mark analysed, detailing the tested version (and
	maybe adjust category).  If they don't have the platform to test,
	request help with this.  If the bug report is bogus, explain why 
	and close it.  If the bug report title is unhelpful, make it 
	clearer.  If a valid, reproducable bug was just sent to gcc-bugs, 
	enter it in GNATS.

This would help make GNATS more usable for finding problems to work on.  
Perhaps some of the volunteers who helped with bug review for 3.0 would be
willing to help with this on an ongoing basis?  Presumably GNATS-only
accounts can be made available for people volunteering for bug review.

> Note that these questions apply to code changes, not documentation
> changes.  We may want to split off proposed patches to the manual
> (that do not accompany code changes) or to the web site onto a separate
> list that would run the way we do now, since we don't have the same
> problems there. (gcc-doc-patches, say).

Every one of those questions applies to documentation changes as well
(though I do attempt to review them for Texinfo problems, but have no
authority to approve most of them).  The patch review problems apply to
them as well; they can wait months for someone to look at them.

> If these tests are all passed, then the patch would enter a tracking
> system.  Perhaps GNATS can be used, even though the patch is not exactly
> a bug.  A new category proposed-patch can be created with the patch
> as an attachment.  We can come up with conventions as to how to use
> the severity and priority fields, we can keep track of what has been
> analyzed, etc.
> 
> I realize that GNATS is not ideal for patch-tracking, but it's already
> in place.

Get a way to go from a web archive URL to a plain text version of a
message (tabs intact, etc.).  (For example, perhaps it could be arranged
for archived messages to include the number of the message in ezmlm's
archives (or the actual *get* email address), so people could mail ezmlm
to retrieve the message, or perhaps every message could have corresponding
files with the plain text of the message and the plain text after MIME
decoding.)  Then patches don't need duplicating in GNATS.

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