On Thursday 09 June 2011, Igor Galić wrote: > ----- Original Message ----- > > > On June 8, 2011 20:11 , Igor =?utf-8?Q?Gali=C4=87?= > > > > <[email protected]> wrote: > > > One of the many good suggestions they propose is to have a > > > "Patch Manager" - someone who makes sure that patches > > > submitted via Bugzilla or directly to the list don't get lost > > > in the noise and that people get some feedback, even if it's > > > just a one liner like "Thanks, we're looking into this", > > > "Nope, that's really not in our scope", etc... > > > > Committers, is there anything that list/community members could > > do to pitch in and help? What, if anything, would be useful and > > accepted? For example, is there a list of things you'd like to > > be done before you > > commit a patch, and are there parts of that list that could be > > delegated > > to one or more non-committer janitors? I'd be willing to try and > > help > > (for example), if such help would be useful. > > As I already pointed out: One of the things that - IMO - needs > touching is Bugzilla. We have far to many bugs which are open. I > suspect a great number to already be either fixed or duplicates of > other bugs. > > So the simplest thing you really can do is to take a look at bugs > that bug you and see if there's other, related -- or equal bugs.
Some more ideas: - I guess a lot of very old bugs that are in the NEEDINFO state can be closed because they cannot be reproduced. Maybe someone could collect a list of candidates. - If a patch is "obviously right" (because it only fixes a typo, etc.), draw attention to it on httpd-dev. - If a patch has been vetoed or critisized as wrong by a commiter, remove the PatchAvailable keyword. - If a patch for a part of HTTPD that is not UNIX-only is obviously written in a UNIX-ish way (i.e. not using apr functions), remove the PatchAvailable keyword and ask for a portable version. - If a patch looks more or less ok, it may be useful to run the test- framework with it and report success or any failures. However not all code parts are covered by the test-framework. I don't know how easy it is for a non-committer to guess if a test run would make sense or would be a waste of time. - If a bug report is about a segfault but does not have a backtrace, ask for the backtrace (pointing to the relevant part of the docs). - If a report is about a crash, hang, or loop, verify that the following information is there: Which OS, which MPM, which version of HTTPD, which openssl version (for ssl related PRs), which ldap libraries (for mod_ldap related PRs). Ask the submitter if not.
