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 each bug/rfe > with something that can be linked to and viewed from within the bug report? I'd say this is both doable and utterly critical. Anyway, glad to see some of this discussion happening- it is my great gnome regret that I didn't force something like it to happen earlier. Luis _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
