bug fixes/patches and developer round-trip time

Daniel Veillard veillard at redhat.com
Fri Aug 15 11:59:06 UTC 2003


On Fri, Aug 15, 2003 at 12:24:55PM +0300, Pekka Savola wrote:
> Hi,
> 
> Perhaps I should bring up one issue that may have not been discussed too 
> much.
> 
> A lot of bug reports which no one has time to fix is bad, of course.
> 
> But what's worse, is that when someone from the community provides e.g. 
> patches or works for fixing those issues, it takes a LONG time to actually 
> get a developer to commit such a fix and get the problem solved.
> 
> IMHO, in cases I've seen this, most of the time it has taken entirely too
> long (even many weeks or months, even for trivial fixes).

  Yep, actually it's a process which can be improved easilly in the
context of Red hat Linux Project, because it's parallelizable. What it
takes is work as part of the bug report triaging to identify bug reports
with patches and make sure they are immediately sent upstream to the
maintainer or project bugzilla. That does not require any priviledged
access to bugzilla, can be split between a pool of volunteers, but can
be a boring task. Availability of patches detection can be mostly
automated if the change is given as an attachment and not as a human
language explanation.
  If you have the energy, building querying tools and setting up 
instructions for other to use should not be that difficult.

  One of the data which would be useful but might be missing right now
is a database associating the package names to their corresponding
upstream contact and bugzilla informations. The URL field present in
the RPM header is a good fist step to lookup the information (I use
it to provide project pointers on rpmfind.net queries, I could make
that database available).

Daniel

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/





More information about the devel mailing list