Actually, I'm fairly sure that most distros _do_ setup sendmail by
default for the user.  However, you are right that it would be nice to
have another alternate submission method; there are some half-written
patches to allow the use of Evolution to send the email (and that was
once an option) but that isn't yet finished.  Perhaps ferulo will have
an idea for that...

Also, as far as your password goes, you can change it.  Click on the
'prefs' link at the bottom of any bugzilla page (which will take you to 
http://bugzilla.gnome.org/userprefs.cgi).

Yep, I'm aware of this. I've ported bug-buddy to send reports via HTTP
POST using libsoup (the bugzilla side is a 10 lines C program or perl
script). The problem of this is that evolution-data-server and libsoup
decission to enter the desktop was after the feature freeze, so I
think I should wait to 2.7 for commiting these changes.
PD: elijah, I changed to just "fer" :)

*** Bug 138244 has been marked as a duplicate of this bug. ***

Now doing with xml-rpc stuff

Has this been commited and so on?

no, the xml-rpc stuff was never committed to libsoup, and our bugzilla still
doesn't have the xml-rpc patches (maybe when migrating to 2.18)

Fer: is there some reason the xml-rpc stuff never got committed to soup?

No one cared about it :).
Now an ubuntu guy working on bug-buddy xml-rpc stuff has finished the patch and
it now being reviewed by Dan on upstream bugzilla.

What is the upstream bug #, fer?

*** Bug 329316 has been marked as a duplicate of this bug. ***

For those who are interested.. the perl XML-RPC support is now installed on the server. This means I can now start making bugzilla.gnome.org allow creating bugs via xml-rpc (I have a basic patch but I want to change how it works). After that Bug-Buddy must be changed to match it.

Olav ROCKS!!!

That is all.  :)

For those who didn't see the http://planet.gnome.org post; New UI can be seen at:
http://www.gnome.org/~fherrera/blog/new-bugbuddy

That demonstrations works currently using the Bugzilla test installation (I need to clean it up a bit before I'll move it to b.g.o).

Things that need fixing / thoughts:
 * Anonymous vs random email address vs Bugzilla user/pass
 * Ask what they where doing; required yes/no?
 * No debugging symbols (I think these are often useless)

Still discussing if all can be fixed before 2.14 and if there is enough in for 2.14.

Because this new UI probably causes loads and loads more crashers to be submitted, I want an ability to detect duplicates (based upon the stack trace). When a bug is a dupe Bug-Buddy should report that to the user (upgrade to latest version or something).
These are files as bug 330321 (xml-rpc support) and bug 330323 (making an UI for developers to reject bugs based upon stack trace).

Furthermore in bug 330147 the xmlrpc branch now also reports memory usage + when the application was started. Allows the developer to quickly see if the app crashed on startup, after 3 days of use, etc.

(In reply to comment #13)
>  * Ask what they where doing; required yes/no?

I think it's easier and more obvious to submit all info without asking.
And then give link to bug (possibly to some customized/simplified page) where user can add comment about what he was doing.

I forgot to add the reasoning behind anonymous/random email address + asking what they did.

As Bugzilla works on email address, a user will need to have a Bugzilla account. We also need to avoid script kiddies creating accounts for some random email address. That is why the password is currently emailed to the email address.

Just dealing with logging in (or creating one if anonymous is allowed) or waiting to receive your password makes me highly prefer users entering this information in bug-buddy.

(In reply to comment #15)
> As Bugzilla works on email address, a user will need to have a Bugzilla
> account.

This needs to be fixed.  Users should be allowed to anonymously submit bug reports.  Yes, that means we have no way of getting extra information.  But it's not exactly like everyone follows up right now despite submitting with their email address -- and in fact, I think it's indicative of how users would prefer to deal with things.  For example, if anything ever crashes for my wife, she makes me do the bug reporting thing--not because she can't follow bug-buddy but because she says that she doesn't want to have to get more email about the issue or be required to follow up.  Having users be marked as the reporter of the bug with their email address should be optional and off by default for bug-buddy bugs, IMO.

(In reply to comment #13)
> Things that need fixing / thoughts:
>  * Anonymous vs random email address vs Bugzilla user/pass
>  * Ask what they where doing; required yes/no?

I think fer's screencast is pretty good.  However, instead of automatically submitting I would like a dialog that says something like:

"The necessary information to report this bug has been gathered.  At this point you can just submit it, or you can review the information and optionally add more details.  Reviewing the information that will be submitted gives you a chance to verify that nothing sensitive gets sent, while adding details about what you were doing and optionally providing an email address where you can be contacted for more information can make it easier to fix the problem."

With buttons like "Cancel without submitting", "Review and add more details", and "Submit information".

> This needs to be fixed. Users should be allowed to anonymously submit bug
> reports.

I do not see how the current process is not anonymous. It asks for an email address which can be created anywhere. The real goal is (as you say) not wanting to do anything more than submit the crasher.

My reason for disliking such anonymous bug reports is that I feel this will overload GNOME developers and the bugsquad, without providing a real benefit to them. Bugs will always be filed.

If we had a real system to track crashers, allowing anonymous and having that as default would make sense. Now every time a user submits a crasher multiple persons (developers+triagers+others) will read that bugreport. I do not think that a crasher that is so unique to not be submitted by a non-anonymous user could be fixed without any input.

On the other hand, if we have good enough tools to easily prevent dupes from being filed (bug 330321) then we could allow it. However, I'm not sure 5 functions are enough to catch all dupes (thinking of the d-d-l discussion when I added the hack to halloween).

(In reply to comment #18)
> I do not see how the current process is not anonymous. It asks for an email
> address which can be created anywhere. The real goal is (as you say) not
> wanting to do anything more than submit the crasher.

It requires an email address -> I don't think it's anonymous.  It can be worked around to effectively achieve anonymity (assuming the user realizes the method and is willing to put up with a huge hassle), yes.  Anyway, you are right that my main goal is definitely ease of submitting, but I think anonymous submitting is an extra worthwhile goal.

> My reason for disliking such anonymous bug reports is that I feel this will
> overload GNOME developers and the bugsquad, without providing a real benefit to
> them. Bugs will always be filed.

It should be easy to keep it from overloading Gnome developers, and I think we can make it not overload the bugsquad either.

> If we had a real system to track crashers, allowing anonymous and having that
> as default would make sense. Now every time a user submits a crasher multiple
> persons (developers+triagers+others) will read that bugreport.

That's also a bug, IMO.  I think bug-buddy bugs (at least those submitted anonymously but probably much more than that) should be filed where only bugsquadders will see them.  Maybe a needs-to-be-triaged product.  That (a) reduces load on developers, and (b) provides some really easy to triage bugs for new bugsquadders (new bugsquadders often have problems finding bugs that need changes and ones that they can recognize; this would make it easy).  It'd also be easy for senior-bugsquadders to check if there were difficult bugs needing triaging that others can't handle--is the needs-to-be-triaged/i-dont-know-where-this-goes/whatever product empty or does it have bugs?

(I also think people filing bugs using bugzilla ought to have the opportunity to file bugs in such a location if they want)

> I do not think
> that a crasher that is so unique to not be submitted by a non-anonymous user
> could be fixed without any input.

Most unique crashers aren't going to be fixed anyway; 95% of needinfo bugs are not followed up on.  Sure, we will lose some information by allowing anonymous submission.  But we are already losing information because people aren't filing bugs due to the email requirement.  It's sort of a tossup, but IMHO our view towards trying to resolve every bug instead of trying to fix as much as possible[1] has limited our overall effectiveness. 

Also, another idea: XML-RPC ought to allow us to check for dupes, right?  If it's a dupe of a needinfo, can we tell the user "we need more info, please help!" while they are still submitting the bug?

> On the other hand, if we have good enough tools to easily prevent dupes from
> being filed (bug 330321) then we could allow it. However, I'm not sure 5
> functions are enough to catch all dupes (thinking of the d-d-l discussion when
> I added the hack to halloween).

It's worth nothing that the fulltext search feature of mysql could probably be used to give us a simple-dup-finder for non-crasher bugs (and, in fact, might work for crasher bugs too).  In fact, I have started some experiments with this and while it definitely wasn't perfect (much like the simple-dup-finder for stack traces leaves something to be desired at times), it does appear that it would be useful.  I intend to work on it more when I have some time.

Oops, forgot the footnote for the last comment:

[1] http://blogs.gnome.org/view/newren/2005/09/30/0

(In reply to comment #19)
> It requires an email address -> I don't think it's anonymous.  It can be worked
> around to effectively achieve anonymity (assuming the user realizes the method
> and is willing to put up with a huge hassle), yes.  Anyway, you are right that
> my main goal is definitely ease of submitting, but I think anonymous submitting
> is an extra worthwhile goal.

My goal is letting the developers only see the good bugreports. Triagers are a part of this. Another part is making sure there aren't so many bugreports that the good ones are lost between the others. This means avoiding dupes and bugreports without enough information, without being too annoying about it.

> > My reason for disliking such anonymous bug reports is that I feel this will
> > overload GNOME developers and the bugsquad, without providing a real benefit to
> > them. Bugs will always be filed.
> 
> It should be easy to keep it from overloading Gnome developers, and I think we
> can make it not overload the bugsquad either.

How? The only way I see is by starting to ignore bugreports. I think we have a better overview of our bugs than Mozilla has. Their entire Bugzilla setup seems to be developed so that they are able to ignore bugreports. (e.g. filed as unconfirmed and never looked at or even seen)

> > If we had a real system to track crashers, allowing anonymous and having that
> > as default would make sense. Now every time a user submits a crasher multiple
> > persons (developers+triagers+others) will read that bugreport.
> 
> That's also a bug, IMO.  I think bug-buddy bugs (at least those submitted
> anonymously but probably much more than that) should be filed where only
> bugsquadders will see them.  Maybe a needs-to-be-triaged product.  That (a)
> reduces load on developers, and (b) provides some really easy to triage bugs
> for new bugsquadders (new bugsquadders often have problems finding bugs that
> need changes and ones that they can recognize; this would make it easy).  It'd
> also be easy for senior-bugsquadders to check if there were difficult bugs
> needing triaging that others can't handle--is the
> needs-to-be-triaged/i-dont-know-where-this-goes/whatever product empty or does
> it have bugs?

I see that as ignoring them. Rather reject than ignore. With rejecting you are clear that you do not care. Ignoring is bad. I do agree with ignoring if Bug-Buddy stated that before the bug was submitted (e.g. for anonymous ones).

Seperate product is evil + loads of issues I do not want to solve. But perhaps an email setting is doable (I'm thinking of adding some keyword to determine the bug-buddy bugs, and having Bugzilla/BugMail.pm use that to for the email setting).

> (I also think people filing bugs using bugzilla ought to have the opportunity
> to file bugs in such a location if they want)

We have the general product. Nobody looks after it in a sane (<1 month) amount of time.

> > I do not think
> > that a crasher that is so unique to not be submitted by a non-anonymous user
> > could be fixed without any input.
> 
> Most unique crashers aren't going to be fixed anyway; 95% of needinfo bugs are
> not followed up on.  Sure, we will lose some information by allowing anonymous
> submission.  But we are already losing information because people aren't filing
> bugs due to the email requirement.  It's sort of a tossup, but IMHO our view
> towards trying to resolve every bug instead of trying to fix as much as
> possible[1] has limited our overall effectiveness. 

I still see this differently. 95% of needinfo bugs isn't followed up, so why accept more anonymous bugs?

> Also, another idea: XML-RPC ought to allow us to check for dupes, right?  If
> it's a dupe of a needinfo, can we tell the user "we need more info, please
> help!" while they are still submitting the bug?

There is no automated check that is good enough to check for dupes. The bug I filed will require manual labor. But I did plan that (read the description of those bugs).

> > On the other hand, if we have good enough tools to easily prevent dupes from
> > being filed (bug 330321) then we could allow it. However, I'm not sure 5
> > functions are enough to catch all dupes (thinking of the d-d-l discussion when
> > I added the hack to halloween).
> 
> It's worth nothing that the fulltext search feature of mysql could probably be
> used to give us a simple-dup-finder for non-crasher bugs (and, in fact, might
> work for crasher bugs too).  In fact, I have started some experiments with this
> and while it definitely wasn't perfect (much like the simple-dup-finder for
> stack traces leaves something to be desired at times), it does appear that it
> would be useful.  I intend to work on it more when I have some time.

If it isn't 99+% perfect, then we cannot use it to automatically request for more information.

I have some other ideas on reducing the duplicates for non-crashers, but that is getting too offtopic.


I'm still thinking about all the issues. Even if all my doubts are resolved, I want to be able to reject all anonymous bugreports when it doesn't work.

(In reply to comment #21)

> My goal is letting the developers only see the good bugreports. 

Agreed, that trumps other goals but I don't see how it's incompatible with any others I listed.

> Triagers are a part of this. Another part is making sure there aren't so many
> bugreports that the good ones are lost between the others. This means avoiding
> dupes and bugreports without enough information, without being too annoying
> about it.

You could achieve that by disabling bug-buddy submissions entirely, yet you don't seem to be advocating that.  Also, having developers automatically see bug buddy submissions, whether anonymous or not, without having bugsquadders look at them first runs contrary to your stated goal.


> > It should be easy to keep it from overloading Gnome developers, and I think
> > we can make it not overload the bugsquad either.
> 
> How? The only way I see is by starting to ignore bugreports.

By doing the other things I suggested, namely, don't email the developers whenever a bug is created from bug-buddy.  Let the bugsquad handle it first.  Note that this does _not_ imply ignoring the bugs.

> I see that as ignoring them.

Then you are misunderstanding.  If the bug has enough info, triagers reassign it, and it gets seen (which follows your goal).  If it's a dupe, it's marked as such (which may still result in an email to developers, but at least it's only one instead of two).  If the bug doesn't have enough information, anonymous submissions are marked as incomplete while non-anonymous ones are closed.

> Separate product is evil + loads of issues I do not want to solve.

Why?

> We have the general product. Nobody looks after it in a sane (<1 month) amount
> of time.

Yes, but that's kind of irrelevant.  That product isn't meant for anything like this and using it as such would be a total misuse.  It's also why we actively discourage it.  Having bug-buddy bugs automatically go into a product which they were meant to be in as a please-sort-me area would mean that bugsquadders automatically look there.  It would also mean that I, personally, would look for bugs in that product that have been there for too long (e.g. more than a week).

> I still see this differently. 95% of needinfo bugs isn't followed up, so why
> accept more anonymous bugs?

"followed up on" is a really bad barometer of usefulness of bug reports, IMO.  If it was, we should stop shipping bug-buddy by default and only have developers and bugsquadders manually install it.

Here's my opinions on why we should accept anonymous submissions:
 - We get more bug reports with potentially useful information (i.e. the same reason we accept bug-buddy reports in the first place)
 - Requiring an email address implies they will be given periodic updates on bug statuses.  Think about it, that's the psychology I've seen behind tons and tons of the complains about bugzilla.  And it's something that we just can't do that--developers are too overloaded to give periodic status updates on all bugs.  This causes people to dislike and distrust our system.  I believe it is the primary reason, that people dislike the system.  And there's lots that don't like it.
 - Users are trying to be nice by providing the information we requested (by having bug-buddy pop up).  Then we demand that they send an email address to a location they don't necessarily know in a day and age where spam is a ridiculously huge problem?  I feel like we're slapping them in the face, quite honestly.

> There is no automated check that is good enough to check for dupes. The bug I
> filed will require manual labor. But I did plan that (read the description of
> those bugs).

Yeah, sorry, I was going on a bit of a tangent.  I agree that we couldn't automate it.  But if there is a really important bug that we need more info on, we could do the manual labor on the server necessary to recognize such bug reports, which would allow bug-buddy to ask the user for more information at submission time, right?

> > It's worth nothing that the fulltext search feature of mysql...
> 
> If it isn't 99+% perfect, then we cannot use it to automatically request for
> more information.

That wasn't the point, sorry if I wasn't clear.  The point is to reduce the load on bugsquadders, just as the simple-dup-finder does now.

(In reply to comment #19)
> It's worth nothing that the fulltext search feature of mysql...

s/nothing/noting/.  Stupid typos.  :-}

(In reply to comment #22)
> (In reply to comment #21)
> 
> > My goal is letting the developers only see the good bugreports. 
> 
> Agreed, that trumps other goals but I don't see how it's incompatible with any
> others I listed.

I believe anonymous reports doesn't have any benefits for the developer, nor the triagers. Reporters I can understand, just not the rest.

> > Triagers are a part of this. Another part is making sure there aren't so many
> > bugreports that the good ones are lost between the others. This means avoiding
> > dupes and bugreports without enough information, without being too annoying
> > about it.
> 
> You could achieve that by disabling bug-buddy submissions entirely, yet you
> don't seem to be advocating that.  Also, having developers automatically see
> bug buddy submissions, whether anonymous or not, without having bugsquadders
> look at them first runs contrary to your stated goal.

Developers should have the ability (for themselves) to decide if they want to see them, as some will be triaging and some not. 

> > > It should be easy to keep it from overloading Gnome developers, and I think
> > > we can make it not overload the bugsquad either.
> > 
> > How? The only way I see is by starting to ignore bugreports.
> 
> By doing the other things I suggested, namely, don't email the developers
> whenever a bug is created from bug-buddy.  Let the bugsquad handle it first. 
> Note that this does _not_ imply ignoring the bugs.

Agree, but only if the developer chooses to not see them.

> > I see that as ignoring them.
> 
> Then you are misunderstanding.  If the bug has enough info, triagers reassign
> it, and it gets seen (which follows your goal).  If it's a dupe, it's marked as
> such (which may still result in an email to developers, but at least it's only
> one instead of two).  If the bug doesn't have enough information, anonymous
> submissions are marked as incomplete while non-anonymous ones are closed.
> 
> > Separate product is evil + loads of issues I do not want to solve.
> 
> Why?

Other product means you have to correct product, component and version somehow. Searching for dupes means I have to search the real product and the hundreds of products bundled together in some special triage 'product'. Every triager needs to reassign the stuff and correct it. Just evil. Also, I watch a lot of products, but not all. Putting it all in one product means triaging all of it. Don't want to.

> > We have the general product. Nobody looks after it in a sane (<1 month) amount
> > of time.
> 
> Yes, but that's kind of irrelevant.  That product isn't meant for anything like
> this and using it as such would be a total misuse.  It's also why we actively
> discourage it.  Having bug-buddy bugs automatically go into a product which
> they were meant to be in as a please-sort-me area would mean that bugsquadders
> automatically look there.  It would also mean that I, personally, would look
> for bugs in that product that have been there for too long (e.g. more than a
> week).

We can do the same if they are filed to the correct product right away and let developers use email settings to disable receiving the email (until keyword is removed.. then they see it).

> > I still see this differently. 95% of needinfo bugs isn't followed up, so why
> > accept more anonymous bugs?
> 
> "followed up on" is a really bad barometer of usefulness of bug reports, IMO. 
> If it was, we should stop shipping bug-buddy by default and only have
> developers and bugsquadders manually install it.

You mean because I'm not considering the Bug-Buddy bugreports that where useful? I am, but I believe anonymous gives us only crap.

> Here's my opinions on why we should accept anonymous submissions:
>  - We get more bug reports with potentially useful information (i.e. the same
> reason we accept bug-buddy reports in the first place)

More bug reports could mean more information. But I do not think the trade-off is worth it. I still see it as loads-of-crap and maybe once a sentence we can use. Yeah, we wouldn't see the sentence. But is that sentence worth all dealing with all the crap?

>  - Requiring an email address implies they will be given periodic updates on
> bug statuses.  Think about it, that's the psychology I've seen behind tons and
> tons of the complains about bugzilla.  And it's something that we just can't do
> that--developers are too overloaded to give periodic status updates on all
> bugs.  This causes people to dislike and distrust our system.  I believe it is
> the primary reason, that people dislike the system.  And there's lots that
> don't like it.

Lots? I do not see that. Some users can be very vocal and complain every time they see something brought up. Doesn't mean there is a big problem (... oGo). 

>  - Users are trying to be nice by providing the information we requested (by
> having bug-buddy pop up).  Then we demand that they send an email address to a
> location they don't necessarily know in a day and age where spam is a
> ridiculously huge problem?  I feel like we're slapping them in the face, quite
> honestly.

Ehr.. they know GNOME. We can tell them the email address isn't shown to the public (needs login currently).

> > There is no automated check that is good enough to check for dupes. The bug I
> > filed will require manual labor. But I did plan that (read the description of
> > those bugs).
> 
> Yeah, sorry, I was going on a bit of a tangent.  I agree that we couldn't
> automate it.  But if there is a really important bug that we need more info on,
> we could do the manual labor on the server necessary to recognize such bug
> reports, which would allow bug-buddy to ask the user for more information at
> submission time, right?

Yes. We have to think about how it works. Ideal process is:
1. Submit stracktrace automatically (to some function that will not create a bug)
2. Determine on server if it has been fixed yet
3a. If fixed: Tell user, exit
3b. If needs_info: Ask user for info?
3c. If needs_contact: Ask user for info + require email address?
3d. If known: Increase some counter to show how often a crash is seen?
3e: If new crash: Ask user for info + email address?
4. Submit stuff again to create a bug (if needed)

3c would require an email address. Not sure about 3e.

Think something like above would solve your and my objections. Furthermore I do not like to ask for information while the bug was already fixed (annoying, wastes time for the reporter).

Above might annoy some persons as it submits information automatically. But when after it crashers the user already clicked the 'inform developers', so think that is enough. We could do the 'verify info to be submitted' at the start of step 4.

Fer: I've changed the bugzilla-test implementation. Please remove username/password arguments. Username should be part of the 'hash' that also holds product. The username should have something like:
  reporters -> email_address

Currently the email address *must* exist.

Also, please try to create bugs with invalid product, component, reporter, etc. It will give an error message back. This is more in line with the experimental patch from Bugzilla upstream, so hopefully these error messages & codes stay the same.

Please also add to the hash:
  priority => 'High'
  bug_severity => 'critical'

And perhaps ensure that the User-Agent specifies 'Bug-Buddy 2.16' or something like that.

The method_call also changed to BugBuddy.createBug instead of Bugzilla.createBug.

Oh, just looked, and I mean soup_xmlrpc_message_start_member above.

I'll try and finish the server part this week.

Typo: s/reporters/reporter/

Oh, and I changed the URL, s/xmlrpc\.cgi/bugbuddy.cgi/

Fer: I'm going to commit the minimal changes to make the xmlrpc branch work with the server changes shortly. This is pretty easy and safe, so hope you do not object.
Noticed one bug... my jhbuild is in Dutch... bug-buddy puts the translated app name in the summary of a bug. That is not what I want. However, that exceeds my limited C skills ;-)

Also do not want the email address to be optional

After some grepping and some trial and error I've added the User-Agent to the request. Only a few issues left for the client:
 * no anonymous
 * remember email address
 * do not translate the app name

For server:
 * create bgo account if email address does not exist

Quick update: Bug-Buddy XML-RPC branch now requires an email address and remembers it. The first time it will also try to fetch the email address from Evolution.

Still have to do the account creation on the server.

For the client also the error messages by the server need to be handled. Brent Smitten is working on this.

Bug-Buddy 2.15.0 for GNOME 2.15.3 has been released with XML-RPC support. Closing this bug. If there is a problem, file a new bugreport.