Mailinglist Archive: opensuse-project (120 mails)

< Previous Next >
Re: [opensuse-project] Suse Bug Reporter - GSoC midterm report
  • From: Mihnea Dobrescu-Balaur <mihneadb@xxxxxxxxx>
  • Date: Tue, 12 Jul 2011 01:12:34 +0300
  • Message-id: <>
On Mon, Jul 11, 2011 at 11:32 PM, Christian Boltz <opensuse@xxxxxxxxx> wrote:

most important thing first: your bugreporting tool (at least what I've
seen in the usage example) looks good :-)

Thank you! :)

Nevertheless, there are always things that can be improved. You probably
already know/remember I'm scaring each and every developer with
bugreports, and you are not an exception ;-)

on Montag, 11. Juli 2011, Mihnea Dobrescu-Balaur wrote:
* aid - helps the user to determine which is the „suspected” package
that causes a problem

Can you paste an example, please?

At the moment the only thing now is a prompt to click on the window of
the program that you want to report against and it will return the
package name via xprop WM_CLASS. Can't paste you an example right now
because I'm replying from my macbook.

* check account - verifies that the user has a valid account and if
so, it stores the user's credentials in a hidden file, base64
encrypted and pickled to make them not human readable; if the data is

Just for the records: base64 does not mean "encryption", it's only
"make it unreadable for humans".

Of course, but I did say that. ( "to make them not human readable" )

Some sample usage for submitting is here [0].

I'll include parts of the sample usage in the mail:

These are the similar bug reports found
  0. python-django-annoying just scheduled and can't commit to OBS

Do you want to contribute to one of the bug reports above or submit a
new one?  yes (contribute)/no (new one)
Yes: contribute
No: submit new

Answer: no

Instead of yes/no, something self-explaining would be good - maybe
   c/n for [c]ontribute / [n]ew

Sure, I can do that.

And please include the bug number of the "similar bug reports" in the
output so that I can check the content if needed.

Well, you can see the list and if you pick one to contribute to it
gives you the bug number and an URL to it. But no problem, I can also
add the bug number in the list.

Getting list of components from Bugzilla for product openSUSE 11.4.
Available components:
  0. Apache                                     1. AppArmor
  2. AutoYaST                                   3. Banshee
  4. Basesystem                                 5. Bootloader
  6. Commercial                                 7. Compiz
  8. Development                                9. Documentation
 10. Evolution                                 11. Firefox
Which one?
Enter a valid index number between 0 and 48:
Index: 8
Using component Development.

The component is a difficult beast (in general, not only in your tool) -
the question is if there is some way to autodetect it based on the
package name.
The special thing in your tool is that you already know the package (and
therefore the assignee), which makes the component less important (but
not superfluous, it's still needed for QA contact, statistics etc.).

My mentor said not to focus on this because of the assignee part, just
like you said. But stil, from what I've said, I have a path from the
rpm info, I could use that. I will check.

Besides that, I'd say you should avoid index "0" - humans usually start
at 1 ;-)  (that's valid for more "choose one" options)

I do place the index number near each entry, but if everybody agrees,
sure, I can shift the numbering, it's easy to do.

This/these address(es) were found:
assignee: bg@xxxxxxxx

I wonder about the assignee - osc maintainer openSUSE:11.4 python gives
me jmatejek@, not bg@.

cc: ['mrueckert@xxxxxxxx', 'ro@xxxxxxxx', 'cgardner@xxxxxxxxxx']

Just curious: where do you get the CC list from? I can't get any of
those people via "osc maintainer".

Make sure you check the devel package. My tool uses osc to check if
the package has a devel package associated and, if so, it gets the
people from that one. You can check the code here [0]. From what I
tested via some manual queries when I was working on it, it was fine.

Do you want to change the assignee? Yes/No

Answer: no
Do you want to add another cc(s)? Yes/No

Answer: no

What about an option to remove someone from the default CC list?

I didn't want to have too many prompts, but I guess you are right, it
wouldn't hurt.

Please describe the impact of the bug, choose a severity for the
Available severities:
  0. Blocker

"Blocker" is a separate field in bnc, not an option for severity.

I did not know that, I've inspired that part from some code of
Michal's (my mentor) and that's the way he used it. I'm not sure where
to put that info in the bug report dictionary, but I'll check again
the source code of python-bugzilla.

  1. Critical
  2. Major
  3. Normal
  4. Minor
  5. Enhancement

Would you like to see their descriptions? Yes/No

Answer: 3
Invalid answer: yes/no only!
Try again: no

Thanks for showing this usability bug yourself ;-)

All the prompts are like that. You can find the functions for console
input/output in the util/ module.

I like the concept zypper uses - in this case it woul mean
"enter a number to choose the severity, or ? to see the description"

I can do that.

It does not annoy users with "do you need help" questions, but still
offers help for those who need it.

Which one?
Enter a valid index number between 0 and 5:
Index: 3

Do you want to add an automatically gathered system description?

Answer: yes

Is the system description gathering the same for all reports or do you
have some special handling to include specific logs - for example the
y2logs when reporting a YaST bug, zypper.log for zypper,*.log for
X bugs, ...?

At the moment, I only gather what you have seen in the sample. If
anybody would help me with what kind of .log would be needed for what
package, I could make some conditionals, of course. The code allows
that easily, I'd say. I'm not sure about the add attachment
functionality (via python-bugzilla, I mean), but I could just append
them at the end of the report, right? Or maybe paste them
automatically to a service like pastebin and add the link to the
report? What do you say?

BTW: Is there a real bugreport in bnc that was created with your tool?

Short answer: no. I completed all the above last week, but I didn't
want to make a report on the running Bugzila instance because I was
afraid not to cause trouble, so I asked my mentor to check it and test
it on the testing Bugzilla instance (we've agreed on that a while
ago). He was in vacation last week and I didn't find anybody else with
rights to use that instance.
Anyway, submitting the bug is a matter of: bug =**, and the data dict is created
correctly. The tool is ready, just need to test sending a bug report.

OK, that are enough bugreports, enhancement requests and questions for
one mail ;-)

No, wait, I have one more:

I thought so! :-P

You can find the repo here: [1]

An OBS repo with a nice RPM package would be nice ;-)

I've never done that and I don't know how, but I will read the wiki
and whatever I can find on the net and I'll package it. I was waiting
on my mentor's input but then the midterm came and I figured I'd
better send the report also here. :)


Christian Boltz

Thanks a lot for your ideas!
To unsubscribe, e-mail: opensuse-project+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-project+help@xxxxxxxxxxxx

< Previous Next >