Repost: bug report: the other side

[John Summerfield]

Arne Chr. Jorgensen wrote:
> Hi,
> 
> I have collected your inputs, while I am also spending - too much time 
> :) - with
> bugzilla, attempting to gain some experience. Your inputs make me 
> improve as well,
> I reckon.
> 
> What I had in mind with my question, had to do with how things work at other
> side of the curtain.
> 
> 1. How does the system appear to them ?  For example, are they presented 
> with
> the same interface and form as I see on my side.
yum install bugzilla

> 
> 2. What do they have at their disposal ? A bunch of machines with all sorts
> of installed platform versions ? Virtual machines ?
rpm -qi kernel

> 
> 3. Are they shipped a package into their user directory and assigned the 
> task ?

They acquire a package and maintain it until they get tired of it. 
Jeremy Katz has been on anaconda at least as far back as RHL 7.x
rpm -q --changelog kernel | less


> 
> 4. How are their days ?  When they wait and wait for information from users,
> how do they experience it ?

Volunteer to look after a package. Or maybe try Debian, it has an 
orphaned package list (nobody to care for them). The details of a 
support job will vary from organisation to organisation, but the basic 
objectives remain the same.

I've not worked on an OSS project (except helping out as on this list) 
so all I can offer is informed speculation.

If you are maintaining a package, you will
1 Create new packages as and when required
2 Examine bug reports and try to fix bugs. Those that are created by 
your part of the project you will fix. Others you may fix or report to 
your supplier. You are the bridge between RH/Fedora and the supplier.
3. Where you have insufficient information, you will solicit more.
4, You will keep an eye on upstream and package new versions for rawhide 
as they become available.
5. Where bugs are reported against th wrong component you will correct 
the error. Presumably you will argue the case from time to time, your 
colleague may not agree with you.

As for equipment, I think Mike Harris said he got a Quad Xeon when the 
started. But then you need a bit of power to build XFree86/Xorg. I 
suspect now that hardware is shared more than then.

I suspect that at RH they have quite an array of different machines and 
that they tend to get new versions regularly, at least for the kernel 
and xorg folk. They can't reproduce my some of problems without my hardware.

I worked on an IBM project a while back, and part of my work was to run 
the standard set of test cases against the latest PL/1 compiler. Some of 
the test cases were around 30 years old!



> 
> Get my drift ?
> 
> Perhaps I should install some replica of what is used at 
> bugzilla.redhat.com ?
> ( is that doable ? )

Sure. The dependency list for bugzilla is fairly long, but it's all there.
> 
> 5. I didn't get any response on my post:" Example of use: python-mozilla ?"
> 
> $ bugzilla --user=USER --password=PWD info  ?  id-number or what ??

Time to install bugzilla and read its documentation.

> 
> Michael Schwendt wrote earlier:
>  > To file bugs, I use the XMLRPC Python interface to bugzilla. Once I
>  >  have a direct link to a ticket, I can open it with a browser if I 
> need to, but
>  > that could be much faster, too.
>  >
> Guess it is the XMLRPC part that I have missed out.  Used all day working
> on bugs reports, and answered questions ,  so  I  would  just  read  some
> of my bug reports.
> 
> Could anyone  give  me  some  example of  the  commands  ?
> 
> 6. Something I have done:
> 
> In part of my document searches, I found that there is a  Add-ons tool 
> to Mozilla Firefox, called "buggy bar". Placed bugzilla.redhat.com in 
> preferences, and I am
> currently experimenting with it. It clearly show some of the importance 
> of thinking how you express certain fields.

Bugzilla is a Mozilla product.