Re: The Future of Bug Buddy

[Colm Smyth <Colm Smyth ireland sun com>]

>From: jacob helixcode com (Jacob "Ulysses" Berkman)
>
>Colm Smyth <Colm Smyth ireland sun com> writes:
>
>> I do most of my work on Solaris (that may come as no
>> great surprise!) where there is a tool pldd to
>> list the shared objects loaded by a process.
>> There is at least one effort to create a similar
>> tool for Linux (see 
>> http://csociety.ecn.purdue.edu/pipermail/plug/2000-May/002417.html)
>> 
>> If Bug Buddy ran pldd (or similar) on a process before it
>> terminates, it then knows at least the runtime code dependencies
>> of the application and could find the version number of each
>> shared object accordingly. This can be done without the need
>> for a package description or a specialised file for Bug Buddy's
>> use.
>
>Yes.  I have thought about using just ldd on the binary, and looking
>at which package owns the library files.  Doing this pldd hack gives a
>bit more information.  I'll probably use it.

To clarify, the main extra information it provides are:
- dlopen()ed shared libraries
- if Bug Buddy process is not related to the application, it
  can also provide accurate information about the effects
  of environment variables such as LD_LIBRARY_PATH and
  LD_PRELOAD

>> This leaves out things like versions of configuration files,
>> data files, etc. that may cause an application to crash,
>> but it's difficult in any case to get version numbers for
>> the various files an app may use so this may not be
>> such a great loss.
>> 
>> Would this meet the information requirements of Bug Buddy
>> without the need for additional meta-data files?
>
>The problems remains of accurately mapping applications to modules and
>modules / packages to bug tracking systems, which I am not sure can be
>done without external data files.

I guess the goal of a bugtracking system is to route bugs to the
people who will fix them. Rather than distributing the knowledge
of bugtracking systems and packages with each GNOME installation,
how about using a single web-site as a gateway for bugs.

I see two options to achieve this:
1. Store the file that maps modules -> packages -> bugtrackers on
   a central GNOME-bugs web-site (with the possibility of caching
   it in the GNOME tree) and have Bug Buddy use this dynamic
   mapping file.
   
2. Have a mail or web service as a real gateway for bugs; the
   mapping information is stored only at this central site and
   it logs the bug and forwards it to the package's bugtracker.
   
There are several advantages:

1. When bugtracking systems, packages and module owners change,
   it is not necessary to update each GNOME installation to
   have the new package->bugtracker mapping file.
   
The next two advantages only apply if a GNOME installation can
define a "bug gateway":

2. Companies that need to record bugs logged by their employees
   could do so by using a bug router on their intranet that
   logs the bug and then forwards it to the bugtracker a
   described above. This can also work around enterprise
   firewall issues.

3. Distributions of GNOME that come with a support option may
   require that the company that provides the distribution
   is the first port of call for support. This is somewhat
   like the company bug-router (2 above).
   
What do you think?

Colm.

>Jacob
>-- 
>"I've got nothing to say but that's ok." -- John Lennon
>
>
>_______________________________________________
>gnome-hackers mailing list
>gnome-hackers gnome org
>http://mail.gnome.org/mailman/listinfo/gnome-hackers

--
Colm Smyth - Sun Microsystems, Ireland - Desktop S/W Engineering
Sun Xtn: 19166    Phone: 353-1-819-9166   Fax: 353-1-819-9200