bug fixes/patches and developer round-trip time

[Pekka Savola]

On Fri, 15 Aug 2003, Daniel Veillard wrote:
> 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.  [...]

I guess this is a case too, but not really my point.

What if there is no upstream, i.e. Red Hat has developed the software?

What if the fix is already implemented in upstream, but the question is 
getting the upstream version merged or the same patch added?

  (note: merging to a new upstream release may be a LOT of more work in
some cases; adding patches as implemented in upstream may be easier,
sometimes, and there would not be the "patch merge horror when we move to
a new upstream release").

More often than not, these things have bitten me at least.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings