From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Joseph S. Myers" To: Joe Buck Cc: Subject: Re: patch tracking Date: Fri, 14 Sep 2001 12:28:00 -0000 Message-id: References: <200109141902.MAA15299@atrus.synopsys.com> X-SW-Source: 2001-09/msg00559.html 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