Re: downstream bugs [was Re: GnomeClient replacement?]
Luis Villa wrote: On 7/19/06, Dan Winship [EMAIL PROTECTED] 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? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: downstream bugs [was Re: GnomeClient replacement?]
On 7/26/06, Brian Nitz [EMAIL PROTECTED] wrote: Luis Villa wrote: On 7/19/06, Dan Winship [EMAIL PROTECTED] 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. 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. Also because GNOME does not take the time to make the benefits clear. I believe part of the job of a distro-focused bugmaster would be to say 'you filed X bugs upstream this quarter; Y percentage of them were fixed by the community', or other such numbers that would clarify the value to the distro. 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. All distros should be pushing for this :) Would it perhaps be useful to have a QA summit at the Boston Summit, where the various distros could compare notes on upstreaming technique, and see if there are ways they could collaborate? 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?) bug-buddy is inching in this direction, but yeah, tied to gdb right now. Would be great to see some investment in this by the distros (who are, after all, the ones directly financially impacted by crashes.) A crash/bug/rfe GUI which allows opt-in/opt-out to avoid privacy law violations. I believe bug-buddy already does this, no? 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?) I like this idea, but would consider it a secondary priority until we can better handle crashes. Baby steps :) A crash/bug/rfe fingerprinter. - Gathers gnome release version, component versions, distribution and whatever else makes this crash/bug/rfe unique. Latest bug-buddy does this now, I believe. - When passed a crash/bug/rfe object attempts to match the stack trace or bug description with known b.g.o bugs. We're getting there ;) 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
Re: downstream bugs [was Re: GnomeClient replacement?]
On 7/19/06, Dan Winship [EMAIL PROTECTED] 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
downstream bugs [was Re: GnomeClient replacement?]
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. -- Dan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: downstream bugs [was Re: GnomeClient replacement?]
On Wed, 2006-07-19 at 09:09 -0400, Dan Winship 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. Debian has something like this. It only does the syncing after the bug has been forwarded upstream, currently the bug has to be forwarded manually. http://lwn.net/Articles/182383/ has a summary. I presume launchpad.net does something similar. Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
