Reporting same bug in different packages
Hello! I want to report a bug, which occurs in two packages (okular, xpdf) exactly the same way. It's a problem with rendering PDFs. What would be the right way: * File two bugs and refer to each other in a additional message * File one bug and refer to the second package * Something different If d.devel.general is the wrong group, I beg you all pardon and would be thankful for naming a proper group. Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telemati_cs_, Techn. University Graz, Austria -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ipmp4c$eio$1...@dough.gmane.org
Re: Reporting same bug in different packages
schrieb Patrick Strasser am 2011-05-02 19:20: >> I want to report a bug, which occurs in two packages (okular, xpdf) >> exactly the same way. It's a problem with rendering PDFs. >> What would be the right way: > >> * File two bugs and refer to each other in a additional message >> * File one bug and refer to the second package Thank you for the detailed answers! I found several other viewers with the same problem, so I'll file the bug under libpoppler5 and leave it to the experts to find the right assignment. > This works if it is for both okular and xpdf and bug resides in both of > them. Do you see thae same in evince? Evince and some others works fine, details in the bug report. >> If d.devel.general is the wrong group [...] > http://www.debian.org/Bugs/Reporting states that “If you are unable to > determine which package your bug report should be filed against, please > send e-mail to the Debian user mailing list [0] asking for advice.”, and > the translation of this page may point the user to a localized list. Thanks, I read the guide, but missed that. Next time I know it ;-) Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telemati_cs_, Techn. University Graz, Austria -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ipovjl$u3h$1...@dough.gmane.org
Re: Reporting same bug in different packages
schrieb Patrick Strasser am 2011-05-03 15:23: > [..] details in the bug report. #625452 Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telemati_cs_, Techn. University Graz, Austria -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ipp1j5$ahg$1...@dough.gmane.org
Re: Reporting same bug in different packages
schrieb Josselin Mouette am 2011-05-03 17:22: > Le mardi 03 mai 2011 à 15:56 +0200, Patrick Strasser a écrit : > Congratulations, you have added yet another bug on the pile that no one > ever reads, since there are no real maintainers for poppler. Now that's really bad. Alternatives? Reporting upstream, reporting against affected packages? Asking someone with PDF knowledge to have a look at it? Regards Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telemati_cs_, Techn. University Graz, Austria -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ipr500$okl$1...@dough.gmane.org
Re: bug reporting workflow is outdated
schrieb Pedro Larroy am 2011-05-22 22:44: > Hi > > I think expecting having a working smtp on laptops, workstations, etc, > is unreasonable these days. > I suggest that we can make an HTTP based bug reporting method. >From my experience as a occasional bug reporter, some thoughts that came to my mind: It's easier to get the mail setup wrong than to get it right. The current procedure assumes you have a working mail configuration at the reporting machine. That assumption is too strong. I need to authenticate to my mail server, and from time to time I'm in a different network that needs a changed configuration that I have to get right before using reportbug. reportbug should default to the worst case, that is: "I do not have a clue how the message will get sent to BTS, just Do The Right Thing(tm)". If someone knows that his/her mail config is working it should be an opt-in to use that. Sysamins or DD/DMs will likely know what to do, others should not need to care. Compare: > Will reportbug often have direct Internet access? (You should answer yes to > this question unless you know what you are doing and plan to check whether > duplicate reports have been filed via some other channel.) [Y|n|q|?]? and > Do you have a "mail transport agent" (MTA) like Exim, Postfix or SSMTP > configured on this computer to send mail to the Internet? [Y|n|q|?]? This should default to No. bug filed ;-) If sending a report fails, the message is saved to /tmp, and no advice is given how to send the message by other means. I'm not afraid of sendmail-ish programs, but I guess most of the non-developer users even don't know what it is, or what to do with the message draft. I understand Pedro's suggestion to implement an additional transport from bugreport to BTS. I do not see a big difference to the mail transport system. What is the advantage of having a mail-only BTS reporting mechanism? One thing would be to have a quite reliably working mail adress of the reporter. There is no difference to a HTTP base reporting system. One can easily get the mail config wrong, intentionally or by accident. In fact, reportbug asks you for your name and mail address. If you really want to be shure you need a three way handshake to verify the mail adress, either way. One thing I can think of is spam. How is spam handled with mail currently? What would be the difference to HTTP? Finally, BTS has a web frontend to read bug report, which I assume is the preferred way of access. Why prohibit this way of transport for the other direction? It does not need to be a web frontend for reporting or replacing reportbug as preferred way to report bugs, just HTTP transport. No one would think if reportbug to rely on mail transport for getting the bug list... Regards Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telemati_cs_, Techn. University Graz, Austria -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ire3if$54t$1...@dough.gmane.org
Re: bug reporting workflow is outdated
schrieb Ian Jackson am 2011-05-24 13:34:
> Patrick Strasser writes ("Re: bug reporting workflow is outdated"):
>> What is the advantage of having a mail-only BTS reporting mechanism?
>
> The advantage is that no-one can make _other_ user interfaces to bug
> submission that we don't want. (Or at least, they are deterred from
> doing so.)
Is it about control?
What prevents someone to make an additional tool to report bugs?
In the scope of packages this could for sure managed by some agreement
which tools are supported and recommend or even accepted in Debian.
In a global scope, one can now make a web tool that generates mails to
reportbug.d.o., you can do nothing about it. You could ad some mechanism
to limit bug submissions from such tools on the Debian side.
In the end the situation with some additional transport would not change
at all in this respect.
> I agree that using http as a transport for reportbug would be fine, in
> itself. But if you read this thread you can see numerous suggestions
> that "if we had an http interface we could also do X Y Z".
Of course that suggestions would be made, and a lot of them would be not
so bad. What's the problem with good ideas?
> Apparently, if we don't want X Y Z done then we must resist an http
> interface for bug submission
I do not see that argument. There is no rule that says that implementing
a requested feature implies a obligation to implement every other
requested feature.
> even if it makes it hard for reportbug to
> work correctly, because it's the thin end of a wedge.
I try hard to read that not as
"We can't make reportbug more usefull, because that means we would end
in implementing a lot of clever things. Lets stay with an limited system
to save the trouble."
One of the greatest features of Debian is its openness for user
contribution. Reportbug should not present a intentional barrier in user
contribution.
> The fat end is a web form for users to submit bugs.
Would that be so bad?
Pros and cons for reportbug HTTP transport:
- You would not get all the meta-info you get with reportbug, like
installed package versions. That is only the case for third-party
reporting tools, not reportbug HTTP transport.
+ You would not rely on email transport alone.
+ Symmetry to the bug database web frontend.
+ HTTP transport is connection orientated, the reporter gets immediately
feedback about his/her submission.
+ No rather complex MTA setup necessary, only proxy setup possibly needed.
Regards
Patrick
--
Engineers motto: cheap, good, fast: choose any two
Patrick Strasser
Student of Telemati_cs_, Techn. University Graz, Austria
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/irgheu$d1a$1...@dough.gmane.org
Re: bug reporting workflow is outdated
schrieb Josselin Mouette am 2011-05-24 17:50: > Le mardi 24 mai 2011 à 17:05 +0200, Patrick Strasser a écrit : >>> The fat end is a web form for users to submit bugs. >> >> Would that be so bad? > > We would get more bug reports. > > We already receive more bug reports than we can handle. We need less bug > reports, but more useful ones. > > Ergo, putting an entry barrier to reporting bugs is not that silly. Developing software for a living based on a bug tracking system I know that dilemma. Too much bugs is not very comfortable. Bug reports are always of too low quality, I've seen a lot of them. On the other side if bugs exists I'd want to fix them rather soon than later. The problems do not go away when you do not look at them. If it is about quality it needs action to educate users or help them writing better bug reports. A good bug reporting system helps the reporter giving information and the developer working with the reports and solve the problems. When it comes to the content, you can divide reports in at least feature request and problems (to avoid the term bug). I consider feature request or wishlist items not as burden, as long as I can sort them out to get a clean view at the problems. I personally like feature requests as they can give you insight in the users perspective of software, and often enough a new idea. Having a big number of open bugs is uncomfortable for sure, but I would not worry about it if most problems are cared for and a lot of feature requests are in the queue. Would be interesting to see the numbers for Debian, but I could not find a statistical breakdown of bug severities in Debian except for RC bugs. Perhaps someone has the numbers... Artificially throttling bug reports annoys users and makes Debian a worse OS. If it is hard to report bugs you will only get the reports of advanced users and only solve problems they can not get around - simple problems for basic users will persist and bug that users that do not have the skill to help themselves. Debian claims to be an universal operating system, for advanced users as well as for users not skilled in computer technology. Raising a bug reporting barrier discriminates non-advanced users, which is really a bad thing - for the users and the makers of Debian. That said, I know that bugs won't solve themselves. I'd like to help to reduce the bug count, for example at the reportbug package. Regards Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telemati_cs_, Techn. University Graz, Austria -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ddbda82.6000...@tugraz.at
Re: bug reporting workflow is outdated
schrieb Sune Vuorela am 2011-05-24 17:33: > On 2011-05-24, Patrick Strasser wrote: >> Pros and cons for reportbug HTTP transport: > > Heh. your pro's is all about the user. > the con is all about the developer. 1) reportbug is about to enable users to help developers solve problems. 2) To quote myselv: > That is only the case for third-party > reporting tools, not reportbug HTTP transport. Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telemati_cs_, Techn. University Graz, Austria -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/irgluo$d29$2...@dough.gmane.org
Getting good bug reports
schrieb Russ Allbery on 2011-05-24 18:55: > Patrick Strasser writes: First, I want to emphasize that I do not at all advocate for a web reporting form. IMO most contributors to this thread do so. I regard the overall process of reporting bugs in Debian very sensible, no need to change in general. I see three issues mixed up here: 1) Web bug reporting facility, ala Ubuntu Launchpad 2) Helping reports writing high quality bug reports 3) Improving reportbug to mitigate bug report drafts that end up in /tmp > Debian bugs tend to be > of considerably higher quality than I see in other projects (like Ubuntu, > for example, where the bug quality is remarkably worse). And, like Ian, I > think some of that may have to do with Debian's bug reporting system, That's about point 1). Again, I do not think that a web-based bug submit front end would help to improve the situation. >> If it is about quality it needs action to educate users or help them >> writing better bug reports. > > Which also no one has time to do. But it turns out that not putting up a > public web form to submit bugs is a fairly good proxy for user education. > It doesn't *fix* the problem, but it does weed out a lot of users who > don't know how to file good bug reports (and some users who do, which is > indeed a drawback). Point 2). I do not think about going out and teaching people to report bugs. I rather think of some helping questions and information for bug reporting newbies. I usually recommend people to read Eric S. Raymond's "How To Ask Questions The Smart Way". reportbug tries hard to collect good information, I think it could improve in helping reports writing good bug reports. >> If it is hard to report bugs you will only get the reports of advanced >> users and only solve problems they can not get around > > This isn't my experience. Debian users seem to be fairly good about > reporting simple problems readily. Point 3). Still it's too hard for a real novice which would like to help to get a bug report not at all out. The starting suggestion for this thread was to add an HTTP based transport path to get around the MTA thing. In the mid 90ies I was starting with a dial up connection, which was expensive, and I was glad that I could queue my outgoing mail and have them shipped together. I needed a working MTA in my box. Nowadays for me there's no point in having a non-local MTA, I have DSL and alway access to my ISPs mail transport system, which means I have direct access to BTS. I just second the proposal to have a backup to the mail transport in form of a HTTP or some other direct connection transport. Nothing more. Mail is fine, having a backup is even better. Regards Patrick [1] http://www.catb.org/~esr/faqs/smart-questions.html -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telemati_cs_, Techn. University Graz, Austria -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/irh0mf$tq4$2...@dough.gmane.org
Re: Getting good bug reports
schrieb Ian Jackson am 2011-05-25 13:46:
> I wrote:
>> Brian May writes ("Re: Getting good bug reports"):
>>> [ explanation of how reportbug is broken right now ]
>>
>> We could solve this if we can avoid the slippery slope problem.
>>
>> Or to put it another way, I would have no objection to an http
>> submission interface to the BTS, provided that everyone understands
>> and agrees that:
I do note think that it exactly needs to be HTTP, but just something
without MTA and a online connection. HTTP is a well understood protocol,
usually working on port 80 - which is one of the least blocked ports -
with proxies - for those networks where direct access is not allowed.
Using port 80 brings advantages in the aspect of having a direct
connection from most hosts.
Using HTTP brings proxy support, but opens the door for easy to
implement additional bug reporting facilities without the control and
quality constraints that come with reportbug.
Why not use some simple non-HTTP-protocol on port 80?
For the workflow I could imagine:
- Try online submission
- if that fails, try email submission
- if that fails, save the bug report to a file and give the user
instructions how to submit the bug later, maybe from a different host.
Patrick
--
Engineers motto: cheap, good, fast: choose any two
Patrick Strasser
Student of Telemati_cs_, Techn. University Graz, Austria
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/irlgju$rp3$1...@dough.gmane.org
