* Ben Collins-Sussman <[EMAIL PROTECTED]> wrote:
FWIW: in the Subversion project, we've assigned the hat of "patch
manager" to a volunteer in the community. He watches patches come in. If any patch goes unanswered for a week or more, the patch manager files
it in the issuetracker. No more lost patches. If anything, it makes
the patches even more prominent -- when developers are scanning the bug
database for a "quickie" to fix, the small patches stand out.
Yeah, I've thought about something similiar. If we don't find something else I'm volunteering to deal with that. Messing up the bug tracker is something I know of :-)
What must be done to the bug tracker we have now to track the patches better?
(I'm not against having something better, but I don't want to see a delay in waiting for some magic tool.)
We can already assign the keyword "PatchAvailable" for entries and mark entries as enhancements or bugs of various severities. People with patches to submit can already manage the data entry themselves.
The people issues are at least:
a) making sure patches submitted on the mailing list are in the db, by prodding the submitter to consult some on-line doc that describes the requirements for submitting a patch
- get the style correct
- use the right diff flavor
- explain how to reproduce the problem and how the patch has been tested
- go to nagoya.apache.org and submit the patch as a PR, not forgetting to flag the entry with PatchAvailable
- make sure that the PR # is in the subject of any on-list discussion of the patch
- remind people that they have the source and can modify the server however they want and that it isn't the worst thing in the world if they have to continually apply the patch locally if it isn't accepted for some reason
b) making sure the submitter gets some response in a reasonable time
the submitter needs a response within a week giving some initial status so s/he knows it isn't quite a black hole
we need to be able to query this, so that the patch manager can regularly query for patches that have no response, and then make sure the submitter knows the status (this is the time to catch procedural errors in the submission)
c) trying to focus some attention on patches in limbo
perhaps getting 3+ people on IRC for an hour every week or so to look through current patches and see make some quick decisions on as many patches-in-limbo as possible
