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.
--
fedora-test-list mailing list
fedora-test-list@xxxxxxxxxx
To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-test-list
