Re: downstream bugs [was Re: GnomeClient replacement?]

[Brian Nitz <Brian Nitz Sun COM>]

Luis Villa wrote:
> On 7/19/06, Dan Winship <danw novell com> wrote:
>   
> > Luis Villa wrote:
> >     
> > > * distros are all crap at getting their bugs upstream, pretty much.
> > > (Some are slightly better than others, at various times.)
> > >       
> > So now that we've got XML-RPC support in bugzilla, it would be insanely
> > cool if someone could write interfaces and code to let you do
> > cross-bugzilla refiling / mark as duplicate / mark as depending on or
> > blocking. (Including cross-bugzilla notifications of relevant changes.)
> >
> > So like, someone files a bug against the panel on SLED, we figure out
> > that it's an upstream bug, but we still want to track it, because it's
> > still a bug against our product too, and it's affecting a customer. So
> > we click a little "refile this upstream and mark the local bug as
> > depending on the upstream one" button, which does just that. Then if we
> > investigate further, we can add comments upstream, or if someone else
> > fixes it and closes the bug upstream, we'd get a notification of that,
> > and can apply the fix and close our bug.
> >     
>
> I strongly believe developing and maintaining such tools would be a
> very worthwhile investment for the various distros- it would reduce
> the duplication of QA by all parties (which is pretty brutal overhead
> right now), increase the speed that fixes get to users (again, a win
> for all parties), so on, so forth. I'd even be willing to argue that
> this is something a paid bugmaster should do, or at least help the
> distros' QA teams with. Obviously not going to be me at this point,
> but something I think the board and advisory board should keep in
> mind.
>
> Luis
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>   
I really like this idea.  We (Sun) had a process for upstreaming bugs 
but when GNOME head moved away from the center of gravity of our user 
base we didn't find it very useful.  Now that we're developing closer to 
head again, we're encouraging non-distro specific bugs to be manually 
upstreamed.   This isn't an easy sell because most QA and customer 
support people are familiar with one tool and one process.  If GNOME was 
the only component in our distribution I'd push to drop our internal bug 
tools entirely and use b.g.o but it isn't.  So I'd like to push 
internally for improving our process for mapping QA bug content to and 
from bugzilla, tools and a good process for managing bugs generated by 
users of legacy GNOME releases would certainly help make the case.  

What, besides bugzilla's XML-RPC support, do we need in order to make 
this work well?  Off the top of my head:

A cross-platform automated crash logger:
   - gathers corefile and symbols when possible
   - modular so that lsof, dtrace and stacktrace fingerprinting can be 
enabled.  (Would it be useful if, when an infrequent bug happened in a 
component the logger could automatically load some more detailed tracing 
modules so that if it happens again we get a better trace?)

A crash/bug/rfe GUI which allows opt-in/opt-out to avoid privacy law 
violations.

An "I hate this/I love this" key which brings up the GUI and passes it 
information about the currently focused widget (or just a screenshot?)

A crash/bug/rfe fingerprinter.
   - Gathers gnome release version, component versions, distribution 
and whatever else makes this crash/bug/rfe unique.
   - When passed a crash/bug/rfe object attempts to match the stack 
trace or bug description with known b.g.o bugs.

A patch<->bug mapper  
   - O.K. maybe this is blue-sky stuff, but one of my pet peeves is 
when bugs are marked as fixed without any indication in the bug as to 
where the patch is, what version the patch applies to...  I'd like to 
see a two way mapping between every fixed bug and the source patch that 
fixed it.  I understand that this is often impossible when one patch 
fixes many bugs or several patches fix one bug and some of the patches 
only apply to patched distribution specific code... but wouldn't it be 
cool to always tag the bits of code responsible for fixing each bug/rfe 
with something that can be linked to and viewed from within the bug report?