Re: forwarding bugs upstream - opt-in, delayed, automated
On Fri, 16 Sep 2011, Lars Wirzenius wrote: On Thu, Sep 15, 2011 at 06:47:52PM -0700, Don Armstrong wrote: I am looking for a set of perl modules which can handle being fed mail and managing a subscription list in response to that mail while also allowing for subscriptions/unsubscriptions from an external interface. Such a thing may not exist at all, but if it does, I would rather like to avoid reinventing the wheel if at all possible. bugs.debian.net uses, or at least used to use, Enemies of Carlotta already for subscribing to bugs. Perhaps that could be used for this as well? Not easily (at least, not without making the integration much tighter.) Basically, it should be possible to subscribe to any bug for which you can currently describe a limit; the full set of these is so large that it would be wasteful to generate all of the mails for them, so the BTS would need to know which limits people actually cared about, and only generate the mails for them. [That part isn't too hard, but properly managing the bounces etc. needs to be done... (and frankly, almost every mail that the BTS generated should probably go through this mechanism with proper bounce processing, etc.x] Don Armstrong -- We want 6. 6 is the 1. -- The Prisoner (2009 Miniseries) _Checkmate_ http://www.donarmstrong.com http://rzlab.ucr.edu -- 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/20110919004140.gj10...@teltox.donarmstrong.com
Re: forwarding bugs upstream - opt-in, delayed, automated
On Thu, Sep 15, 2011 at 06:47:52PM -0700, Don Armstrong wrote: I am looking for a set of perl modules which can handle being fed mail and managing a subscription list in response to that mail while also allowing for subscriptions/unsubscriptions from an external interface. Such a thing may not exist at all, but if it does, I would rather like to avoid reinventing the wheel if at all possible. bugs.debian.net uses, or at least used to use, Enemies of Carlotta already for subscribing to bugs. Perhaps that could be used for this as well? -- Freedom-based blog/wiki/web hosting: http://www.branchable.com/ signature.asc Description: Digital signature
Re: forwarding bugs upstream - opt-in, delayed, automated
On Sep 15, 2011, at 06:47 PM, Don Armstrong wrote: On Wed, 14 Sep 2011, Barry Warsaw wrote: Can you provide a bit more detail on this? I am looking for a set of perl modules which can handle being fed mail and managing a subscription list in response to that mail while also allowing for subscriptions/unsubscriptions from an external interface. Such a thing may not exist at all, but if it does, I would rather like to avoid reinventing the wheel if at all possible. Thanks. I don't know what you need but maybe it's something that Mailman 3 could help with? Mailman3 isn't finished and is a complete system for dealing with standard mailing lists which don't get created or deleted on the fly. I can't/won't help with the Perl bits, and don't want to clutter up this mailing list with discussions of MM3, but if you're interested in exploring possibilities or influencing its feature set, please contact me off-list. Cheers, -Barry signature.asc Description: PGP signature
Re: forwarding bugs upstream - opt-in, delayed, automated
On Wed, 14 Sep 2011, Barry Warsaw wrote: On Sep 13, 2011, at 04:48 PM, Don Armstrong wrote: The main thing that is blocking me from implementing it currently is a set of perl modules which can handle the hard bit of managing a mailing list correctly so I don't have to write them from scratch. Can you provide a bit more detail on this? I am looking for a set of perl modules which can handle being fed mail and managing a subscription list in response to that mail while also allowing for subscriptions/unsubscriptions from an external interface. Such a thing may not exist at all, but if it does, I would rather like to avoid reinventing the wheel if at all possible. I don't know what you need but maybe it's something that Mailman 3 could help with? Mailman3 isn't finished and is a complete system for dealing with standard mailing lists which don't get created or deleted on the fly. Don Armstrong -- Sentenced to two years hard labor (for sodomy), Oscar Wilde stood handcuffed in driving rain waiting for transport to prison. If this is the way Queen Victoria treats her prisoners, he remarked, she doesn't deserve to have any. http://www.donarmstrong.com http://rzlab.ucr.edu -- 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/20110916014752.gh10...@teltox.donarmstrong.com
Re: forwarding bugs upstream - opt-in, delayed, automated
Hi Stefano (et al.)!
Stefano's post contains a fair assessment of our discussion. However I
would like to state in my own words the basic idea. I'll also provide
a couple of ideas of implementation details.
the problem
--
Often issues that ought to be sent upstream, aren't.
This is *the worst thing* in my view.
I saw real bug reports years old, with no activity, that I could have
easily fixed.
The most brain-dead solution of sending all reports upstream could be
viewed as spamming,
for 2 reasons:
* it wasn't requested
* it contains stuff (about packaging issues, etc) of no interest upstream
status quo
-
*If upstream is aware of the option*, they can choose to be advised of
all bugs or none.
This gives upstream some control, and protects downstream from
accusations of spamming, since upstream has to subscribe to mailings.
But it's all-or-nothing. If upstream subscribes, they still get a
load of reports about packaging issues, etc, that should have been
dealt with downstream.
synthesis
---
It is possible for upstream to get all bug reports that aren't handled
downstream, and for downstream to provide a real service for upstream,
at minimal expense.
First, upstream should have to subscribe to receive any reports.
However, as Stefano mentioned, another option would be provided. I called it
Receive only triaged reports.
I pictured the downstream responder assessing whether the problem was
for upstream or downstream, and just clicking a button -- like
Report Upstream,
which would send the report upstream immediately.
Finally, so that no reports slip through, if the report's status isn't
changed, and the report isn't sent upstream, before some prescribed
time-out, the report is automatically sent upstream.
Of course, it is bad that this should happen, and perhaps a discussion
should ensue, but it is MUCH WORSE to let a real bug report just sit
there.
Furthermore, various other possibilities of tracking reporting
statistics would be possible with such an arrangement.
Cheers!
--
On Tue, Sep 13, 2011 at 3:14 PM, Stefano Zacchiroli z...@debian.org wrote:
After GHM [1], I've head a lengthy discussion with Steve White (Cc:-ed,
GNU maintainer [upstream]) about Debian's procedures for forwarding bugs
upstream.
[1] http://lists.debian.org/debian-project/2011/09/msg4.html
The conversion touched the usual suspects:
- Debian is committed to forward bugs upstream
- that should happen in a timely manner but only after triaging
(otherwise many upstream will get upset for non relevant reports)
- due to manpower issue that does not always happen (timely) and some
upstream might get upset about that
- PTS subscriptions mitigate the problem, but only for upstreams willing
to withstand the load of all untriaged Debian bugs (that might be
significant and prone to many false positives for popular software)
A tentative bottom line of the discussion is that:
- we are not always doing our part in forwarding bugs upstream (of
course: we try hard, but we can surely do better) and there will
always be corner cases (e.g. MIA maintainers, orphaned packages, etc.)
- we do offer mechanisms that upstream could use to mitigate the
problem, but they have significant drawbacks
Steve suggested a feature that might improve the status quo:
- enable people to subscribe to bug traffic only if it matches specific
tags (the idea being of forwarding upstream only the traffic for
confirmed bugs)
- add a DELAYED-like mechanism where upstream is notified of a bug only
if the package maintainer fails to deal with the bug in a specific
timeframe, say, 10 days (deal with may be defined in various ways,
e.g.: post to the bug log, closes the bug, details need to be
fleshed out a bit on this point)
Both features will most likely end up being proper feature requests
against the BTS and/or the PTS. They look completely non-intrusive with
respect to what we already offer and they will be opt-in anyhow. The
DELAYED part is not entirely trivial to implement, but Steve is
interested in helping out.
The main reason why I'm posting here is to gather feedback about the
idea, in particular from people willing to try guessing whether their
respective upstreams could benefit from something similar or not.
Many thanks to Steve for the interesting discussion!
Cheers.
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences .. http://upsilon.cc/zack .. . . o
Debian Project Leader ... @zack on identi.ca ... o o o
« the first rule of tautology club is the first rule of tautology club »
--
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/CAEmWKkS6v_q_hNBMoW2dE5MgZAq=Wv5j_t=o+tvhim3sj+o...@mail.gmail.com
Re: forwarding bugs upstream - opt-in, delayed, automated
Hi, status quo - *If upstream is aware of the option*, they can choose to be advised of all bugs or none. This gives upstream some control, and protects downstream from accusations of spamming, since upstream has to subscribe to mailings. But it's all-or-nothing. If upstream subscribes, they still get a load of reports about packaging issues, etc, that should have been dealt with downstream. even if upstream is interested in bug reports (may be even in all of them) - it is not that easy to figure out how to subscribe to the bug mails of a package. We should make it easier for upstreams to subscribe to bts mails. May be also implement a weekly summary of bug mails instead of spamming every single bug mail. Just my 2c :) Cheers, Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- 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/4e7098cf.6000...@bzed.de
Re: forwarding bugs upstream - opt-in, delayed, automated
On Sep 13, 2011, at 04:48 PM, Don Armstrong wrote: The main thing that is blocking me from implementing it currently is a set of perl modules which can handle the hard bit of managing a mailing list correctly so I don't have to write them from scratch. Can you provide a bit more detail on this? I don't know what you need but maybe it's something that Mailman 3 could help with? -Barry signature.asc Description: PGP signature
Re: forwarding bugs upstream - opt-in, delayed, automated
On Wed, Sep 14, 2011 at 02:06:39PM +0200, Bernd Zeimetz wrote:
even if upstream is interested in bug reports (may be even in all of
them) - it is not that easy to figure out how to subscribe to the bug
mails of a package. We should make it easier for upstreams to subscribe
to bts mails. May be also implement a weekly summary of bug mails
instead of spamming every single bug mail.
This is a bit tangential to the rest of the discussion, but exactly the
same has occurred to me. We do have useful Reply or subscribe to this
bug. notices on individual bug pages, but we have nothing of the sort
for pkgreport.cgi pages.
Does anyone care to propose a feature request (possibly with patch) for
the corresponding template with a short mention that the PTS could be
used to subscribe to package bugs? As we already have a line mentioning
the PTS, that could probably be done using very little extra space (for
a lot of benefit, IMHO).
Cheers.
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences .. http://upsilon.cc/zack .. . . o
Debian Project Leader... @zack on identi.ca ...o o o
« the first rule of tautology club is the first rule of tautology club »
signature.asc
Description: Digital signature
Re: forwarding bugs upstream - opt-in, delayed, automated
On Tue, 13 Sep 2011 15:14:33 +0200, Stefano Zacchiroli wrote: Steve suggested a feature that might improve the status quo: I like the idea. - enable people to subscribe to bug traffic only if it matches specific tags (the idea being of forwarding upstream only the traffic for confirmed bugs) I'd say: tagged confirmed + upstream (confirmed alone can also be set on a packaging-specific bug) and no forwarded field (if it's already forwarded they know about it already). Cheers, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - PGP/GPG key ID: 0x8649AA06 : :' : Debian GNU/Linux user, admin, developer - http://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of Free Software Foundation Europe `-NP: Dire Straits: Wild West End signature.asc Description: Digital signature
Re: forwarding bugs upstream - opt-in, delayed, automated
Stefano Zacchiroli z...@debian.org writes: Steve suggested a feature that might improve the status quo: - enable people to subscribe to bug traffic only if it matches specific tags (the idea being of forwarding upstream only the traffic for confirmed bugs) I'd love this, even with having only my BTS-junkie hat on. This would allow me to subscribe to, say, security or $arch-related bugs for a select number of packages I depend on for $work, or packages I'm more familiar with. Without the disadvantage of also receiving all kinds of reports I can't do a thing about. This would certainly be a far more pleasant experience than subscribing to -bugs-dist and trying to filter based on how many messages a particular bug received, and how often certain words appeared in the messages.. While none of my current upstreams would be interested in this feature, I think, I do know that there are upstreams, who would be very interested. - add a DELAYED-like mechanism where upstream is notified of a bug only if the package maintainer fails to deal with the bug in a specific timeframe, say, 10 days (deal with may be defined in various ways, e.g.: post to the bug log, closes the bug, details need to be fleshed out a bit on this point) For similar reasons that I liked the other suggested feature, I see great value in this one too: mortal users can subscribe to packages they depend on, or know better than others, and easily get notified when the package needs manpower. -- |8] -- 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/87r53kjx19@luthien.mhp
Re: forwarding bugs upstream - opt-in, delayed, automated
On 09/13/2011 03:14 PM, Stefano Zacchiroli wrote: - enable people to subscribe to bug traffic only if it matches specific tags (the idea being of forwarding upstream only the traffic for confirmed bugs) - add a DELAYED-like mechanism where upstream is notified of a bug only if the package maintainer fails to deal with the bug in a specific timeframe, say, 10 days (deal with may be defined in various ways, e.g.: post to the bug log, closes the bug, details need to be fleshed out a bit on this point) Both features will most likely end up being proper feature requests against the BTS and/or the PTS. They look completely non-intrusive with respect to what we already offer and they will be opt-in anyhow. The DELAYED part is not entirely trivial to implement, but Steve is interested in helping out. The DELAYED one should be easy to implement as the BTS SOAP interface [1] already has the notion of a log_modified attribute which holds the DateTime of last update of the bug (and a date attribute which is the DateTime of creation of the bug). The tags attribute in the BTS SOAP interface obviously contains the bug tags, but I'm unsure if that would be enough. It could be a start for confirmed, security and the like though. Should it be implemented in the PTS? How would DELAYED be defined, a fixed amount of days old? How would the selection of the tags be done? Cheers Luk [1] http://wiki.debian.org/DebbugsSoapInterface -- 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/4e6f90fb.7010...@debian.org
Re: forwarding bugs upstream - opt-in, delayed, automated
Quoting Stefano Zacchiroli (z...@debian.org): After GHM [1], I've head a lengthy discussion with Steve White (Cc:-ed, GNU maintainer [upstream]) about Debian's procedures for forwarding bugs upstream. [1] http://lists.debian.org/debian-project/2011/09/msg4.html The conversion touched the usual suspects: This is indeed the consequence of a discussion we (font packages maintainers) had with Steve about the ttf-freefont package (which Steve is upstream for). Great to see that it lead to something interesting Steve suggested a feature that might improve the status quo: - enable people to subscribe to bug traffic only if it matches specific tags (the idea being of forwarding upstream only the traffic for confirmed bugs) - add a DELAYED-like mechanism where upstream is notified of a bug only if the package maintainer fails to deal with the bug in a specific timeframe, say, 10 days (deal with may be defined in various ways, e.g.: post to the bug log, closes the bug, details need to be fleshed out a bit on this point) I think these are really interesting features and I would have loved having them handy when we had this mail discussion with Steve about the status of some ttf-freefont bugs..:-) Thanks for having the discussion face to face (which is always much easier than asynchronously by mail) and ending up with both these features. I know at least of one of my upstreams who would appreciate them, namely Steve himself..:-) signature.asc Description: Digital signature
Re: forwarding bugs upstream - opt-in, delayed, automated
On Tue, 13 Sep 2011, Gergely Nagy wrote: Stefano Zacchiroli z...@debian.org writes: Steve suggested a feature that might improve the status quo: - enable people to subscribe to bug traffic only if it matches specific tags (the idea being of forwarding upstream only the traffic for confirmed bugs) I'd love this, even with having only my BTS-junkie hat on. This would allow me to subscribe to, say, security or $arch-related bugs for a select number of packages I depend on for $work, or packages I'm more familiar with. Without the disadvantage of also receiving all kinds of reports I can't do a thing about. A fully formed system which does this would be excellent. The main thing that is blocking me from implementing it currently is a set of perl modules which can handle the hard bit of managing a mailing list correctly so I don't have to write them from scratch. Given one that doesn't suck, I'd be able to implement this soonish. Don Armstrong -- You think to yourself, hey, it's a test tube, for God's sake. Pretty soon, though, the rush from a test tube isn't enough. You want to experiment more and more. Then before you know it, you're laying in the corner of a lab somewhere with a Soxhlet apparatus in one hand, a three neck flask in the other, strung out and begging for grant money. -- Tim Mitchell, 1994 Ig Nobel Chemistry Prize Speech http://www.donarmstrong.com http://rzlab.ucr.edu -- 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/20110913234848.gm16...@rzlab.ucr.edu
Re: Forwarding bugs upstream
On Wed, Jan 19, 2011 at 9:27 AM, Nikita V. Youshchenko yo...@debian.org wrote: Then, maybe explicitly request upstream - at appropriate forums and in appropriate polite wording - to help debian team(s) to handle the bug report stream? I think upstream has the same problem in some cases: too many bug reports. So I doubt upstream has time to look at yet another bug tracker. -- Olaf -- 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/aanlktinq4tedjy6jcw_m0dmjxkz8pvtcydoeovper...@mail.gmail.com
Re: Forwarding bugs upstream
Hi, Olaf: On Thursday 20 January 2011 09:51:27 Olaf van der Spek wrote: On Wed, Jan 19, 2011 at 9:27 AM, Nikita V. Youshchenko yo...@debian.org wrote: Then, maybe explicitly request upstream - at appropriate forums and in appropriate polite wording - to help debian team(s) to handle the bug report stream? I think upstream has the same problem in some cases: too many bug reports. That I had always problems to believe. I think that usually translates to too many bugs. -- 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/201101201132.38570.jesus.nava...@undominio.net
Re: Forwarding bugs upstream
Hi After reading this thread, I've got a strange thought. So teams maintaining important projects in Debian can't handle the load caused by bug report stream. Large presentange of bugs actually as upstream bugs. If so, upstream should be interested in that information non less than in any other information about bugs in their software. Also, upstream should be interested in having their software in distributions in as good shape as possible - distributions are *the* channel how most users get upstream's software. Then, maybe explicitly request upstream - at appropriate forums and in appropriate polite wording - to help debian team(s) to handle the bug report stream? Sure this will cause requests to put bug report into upstream trackers. Situation with this has been described within this thread, and this information - in brief form - could be presented to upstreams. I think this method could attact additional resource into solving the problem being discussed in this thread. Just wanted to share my thought. Nikita signature.asc Description: This is a digitally signed message part.
Re: Forwarding bugs upstream
On Wed, 12 Jan 2011 13:27:23 + (UTC), Sune Vuorela nos...@vuorela.dk wrote: On 2011-01-11, brian m. carlson sand...@crustytoothpaste.net wrote: I've noticed a trend lately that I am often asked to forward the bugs I report to the Debian BTS upstream, either by the maintainers or automatically by a bug script. I believe, and I continue to believe, I have considered to take this one step further. Close bugs reported in Debian BTS with a severity of important or less that is a bug that should primarily be fixed upstream. This attitute of the Qt/KDE team has stopped me from repoting bugs in KDE packages completely. Currently, the debian Qt/KDE team has around 800 open, non-forwarded bugs reported against their packages. I would guess that maybe 20 of them is packaging issues. But we can't find them. Just usertag the non-packaging issues and filter them out in your queries. The rest of the bugs (780 open-non forwarded (and 300 forwarded)) is pure upstream issues. They're still issues present in current Debian. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- 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/e1pe94q-0005yg...@swivel.zugschlus.de
Re: Forwarding bugs upstream
On 2011-01-13, Andreas Tille andr...@an3as.eu wrote: In short: The Debian maintainer is responsible that a bug will be reported upstream. I don't see a problem if he delegates the actual work to somebody else who is able and willing to do the job (but please be nice to the user when asking for this kind of help). Free software lives from cooperation. Hi Andreas. Would you like to be delegated to help reporting bugs in packages maintained by Qt/KDE team upstream? /Sune -- 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/slrnij035o.rvp.nos...@sshway.ssh.pusling.com
Re: Forwarding bugs upstream
[Jesús M. Navarro] Dear Jesus. Are you seriously saying that - the kernel mainatiners should step down - the xorg maintainers should step down - the mozilla maintainers should step down - the gnome maintainers should step down - the kde maintainers should step down - the xfce maintainers should step down - the openoffice/libre office maintainers should step down If they are not ready to take over their shoulders what it takes to do it properly, undoubtly yes. And who do you think should step up ? Not my problem. I grepped through the Sources file but couldn't find your name anywhere, as maintainer or comaintainer. I guess that means when you say it isn't your problem, you really mean it. Got any more advice for those of us actually doing the work, while you're here anyway? -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- 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/20110114093612.gh13...@p12n.org
Re: Forwarding bugs upstream
[Jesús M. Navarro] If any, bugs you (properly) pass to the upstream developer are bugs that will cost you not a dime of your valuable time from them on. You didn't read the rest of the thread, did you? If you understand what I said, good; if you didn't, please, make me the honour of considering me as an authority and act accordingly No. If you don't like our parties, you are free not to come here. In other words: if you find Bacula to be too hard a package to deal with you are free to orphan it. Why is it that none of the people who keep calling for everyone to orphan their packages because they're not taking on enough of what a maintainer is supposed to do, seem to be stepping up to maintain, co-maintain, or otherwise help out with these packages that are apparently so poorly maintained? -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- 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/20110114092957.gg13...@p12n.org
Re: Forwarding bugs upstream
On Fri, Jan 14, 2011 at 08:43:36AM +, Sune Vuorela wrote: On 2011-01-13, Andreas Tille andr...@an3as.eu wrote: In short: The Debian maintainer is responsible that a bug will be reported upstream. I don't see a problem if he delegates the actual work to somebody else who is able and willing to do the job (but please be nice to the user when asking for this kind of help). Free software lives from cooperation. Hi Andreas. Would you like to be delegated to help reporting bugs in packages maintained by Qt/KDE team upstream? In case this is no intentional missunderstanding of my mail some additional answer for you: In case I would report a bug against Qt/KDE and you consider the problem concerns upstream and you (or somebody who maintains the Qt/KDE related package in question) think that my understanding of the problem is deep enough to have some reasonable conversation with upstream about this topic - yes for sure, I would not be astonished if you ask me to take over the job of forewarding exactly this problem. Kind regards Andreas. -- http://fam-tille.de -- 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/2011011410.ga17...@an3as.eu
Re: Forwarding bugs upstream
Hi, Peter: On Friday 14 January 2011 10:29:57 Peter Samuelson wrote: [Jesús M. Navarro] If any, bugs you (properly) pass to the upstream developer are bugs that will cost you not a dime of your valuable time from them on. You didn't read the rest of the thread, did you? Yes I did. And I stay with what I said. It seems that passing info around is wasting the maintainer's time because (so I assume, since there's no indication implying otherwise) he is just acting as a man-in-the-middle. Once he is able to reproduce the bug himself then he is not acting as the maintainer in front of the upstream developer but as end user with a bug in his hands. If that's not the case, well, I already stated what should be done (basically, close the bug as non reproducible here). You did read the rest of the thread, did you? If you understand what I said, good; if you didn't, please, make me the honour of considering me as an authority and act accordingly No. Whatever. If you don't like our parties, you are free not to come here. In other words: if you find Bacula to be too hard a package to deal with you are free to orphan it. Why is it that none of the people who keep calling for everyone to orphan their packages because they're not taking on enough of what a maintainer is supposed to do, seem to be stepping up to maintain, co-maintain, or otherwise help out with these packages that are apparently so poorly maintained? Because, for whatever reason, they (me) are not debian developers, therefore they didn't make their issue to maintain, co-maintain or otherwise help out with these packages. Those opting to be or in fact being debian developers do it. That said, asking for help prior to orphan a package its maintainer is not up to properly cope with by himself is certainly a valuable option. Cheers. -- 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/201101141132.48667.jesus.nava...@undominio.net
Re: Forwarding bugs upstream
As new (sponsored) mantainer i have a few things to say about this thread. First of all. If i receive a bug report, i do my best to handle it in the rigth way, i am in contact with upstream author and fortunately i have no bugs in my package. I personally don't care to forward bugs to upstream. But i only mantain one package, and it's very simple to handle it. But i am also debian user (looks like some people forgets that DD, DM, and Contributors are also debian users), and as a RESPONSIBLE user i also try to report the bugs i found where they belong. Someone has said that this is comunity project and colaborate is the only way to handle it. Yes, BUT, again, some people think that only DD, DM, and Contributors have to colaborate and not only that, it seems that they are ONLY there to provide a service to the user. If this is really a comunity everyone has to do his little effort. Not only DD or DM. I can underestand Jesus in a way, because time ago i received what i think it was a despective and bad response from a mantainer when i asked some help to adopt one of his packages. But I also have received good words and a lot of help from others (one of them has responsed to this thread). I used to be a really active member of forums but i get tired because i felt that users tend to use forums as a Service of attention to the client instead of a place to exchange knowledge. I see now that it is not only a forums issue. 2011/1/14 Sune Vuorela nos...@vuorela.dk Hi Andreas. Would you like to be delegated to help reporting bugs in packages maintained by Qt/KDE team upstream? /Sune I would be glad if i could help you in that (or any) way sune. Unfortunately mi knowledge is not good enough as i would like to, but anyway feel free to CC me some bugs and i'll see if i am ready enough to help in that way. Iker
Re: Forwarding bugs upstream
On 2011-01-14, Iker Salmón San Millán sha...@esdebian.org wrote: 2011/1/14 Sune Vuorela nos...@vuorela.dk Hi Andreas. Would you like to be delegated to help reporting bugs in packages maintained by Qt/KDE team upstream? /Sune I would be glad if i could help you in that (or any) way sune. Unfortunately mi knowledge is not good enough as i would like to, but anyway feel free to CC me some bugs and i'll see if i am ready enough to help in that way. Any help is most appreciated, especially with handling the bug load. And it really doesn't require any special skills for most bugs. We have written a bit about what's needed here: http://pkg-kde.alioth.debian.org/bugs.html and feel free to contact me in #debian-qt-kde on irc.debian.org, (but I'm away for the weekend, so please wait until monday) /Sune -- 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/slrnij0ctm.rvp.nos...@sshway.ssh.pusling.com
Re: Forwarding bugs upstream
Le jeudi 13 janvier 2011 à 11:54 +0100, Olaf van der Spek a écrit : Instead of stepping down, it might be better to ask for a co-maintainer. I hereby request a new co-maintainer for the GNOME packages. -- .''`. : :' : “You would need to ask a lawyer if you don't know `. `' that a handshake of course makes a valid contract.” `--- J???rg Schilling -- 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/1295005031.7025.44.camel@meh
Re: Forwarding bugs upstream
Hi! Am 13.01.2011 11:54, schrieb Olaf van der Spek: Now we just need to define what a proper job is. Instead of stepping down, it might be better to ask for a co-maintainer. You mean like this http://www.debian.org/devel/wnpp/help_requested? Let's have a look: # chromium-browser [..] requested 228 days ago. # dpkg [..] requested 2245 days ago. # grub2 [..] requested 2439 days ago. # libreoffice [..] requested 1368 days ago. Any other good ideas? Perhaps something new ideas, which isn't already practices? Best regards, Alexander -- 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/4d3038d4.50...@schmehl.info
Re: Forwarding bugs upstream
On Fri, Jan 14, 2011 at 12:51 PM, Alexander Reichle-Schmehl alexan...@schmehl.info wrote: Hi! Am 13.01.2011 11:54, schrieb Olaf van der Spek: Now we just need to define what a proper job is. Instead of stepping down, it might be better to ask for a co-maintainer. You mean like this http://www.debian.org/devel/wnpp/help_requested? Let's have a look: # chromium-browser [..] requested 228 days ago. # dpkg [..] requested 2245 days ago. # grub2 [..] requested 2439 days ago. # libreoffice [..] requested 1368 days ago. Any other good ideas? Perhaps something new ideas, which isn't already practices? There are lots of packages with old bugs without any comments that are not on that list. Olaf -- 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/aanlktikbtzecpfqqz_0mfgpycxtyq5tnh_i+yycvq...@mail.gmail.com
Re: Forwarding bugs upstream
On Fri, Jan 14, 2011 at 11:29:58AM +, Sune Vuorela wrote:
We have written a bit about what's needed here:
http://pkg-kde.alioth.debian.org/bugs.html
A while ago I've reviewed a little bit which kind of contributions
distros are looking for, from people who are willing to get involved
with the distro (see #608400 for a corresponding goal).
Most distros are looking for bug triager and providing specific
documentation to train contributors in that direction. Historically in
Debian we haven't looked for that, beside the very much understandable
periodic cries for help from maintainers of popular package suites
(GNOME, KDE, etc.).
Maybe its time to generalize that? For instance, it seems to me that
most of the above documentation by the KDE team is general and can be
used to document a general bug triaging task on our how to
contribute pages? Looking on wiki.d.o and www.d.o we don't seem to have
much (any?) of it.
Would anyone be against inviting explicitly that kind of contributions?
Note: I'm well aware that some contributors are going to make mistakes
and do bad triaging at times, there's now way around that, but I don't
think it's a valid reason not to try.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams
signature.asc
Description: Digital signature
Re: Forwarding bugs upstream
On Thu, 13 Jan 2011 00:38:37 +, Ian Jackson wrote: Felipe Sateler writes (Re: Forwarding bugs upstream): On Wed, 12 Jan 2011 16:56:56 +, Ian Jackson wrote: I think it is always reasonable for the maintainer to forward the bug upstream. But what I think is bad is _demanding_ or _requiring_ the maintainer to forward the bug upstream. If they don't want to do that for whatever reason then asking the submitter to do so is IMO perfectly acceptable. We can't demand or require anyone to do anything. Yet we expect maintainers to answer bug reports, provide packages, etc. The fact that you can't force anyone to do anything doesn't mean you can't say that some behavior is preferred or considered best practice. Yes. But in this case I don't think we should be expecting maintainers to necessarily shepherd bug reports upstream. I don't think a maintainer who fails to do so is failing in their job as maintainer. The maintainer should decide whether they think doing that is a useful thing to be doing for that package or that bug, and communicate this decision to the user (and set the bug state accordingly). Just like they do about their whole debian work: prioritizing work and their own free time. My point is more along the lines of Bernhard's comment: packages where the maintainer takes (well-defined) reports upstream are better maintained than packages where the maintainer does no such thing. Going back to the OP's comment, when one takes the time to fill a well- described report, maybe even write a patch for it, the maintainer should (again, time permitting) forward the request upstream. I do not think it is reasonable to expect every bug reporter to register in upstream's bug tracker (unfortunately, a big bunch of upstreams require registration, even for their mailing lists!), specially when the maintainer should have already an account. -- Saludos, Felipe Sateler -- 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/igpja8$inb$1...@dough.gmane.org
Re: Forwarding bugs upstream
On Thu, 13 Jan 2011 10:27:12 +, Sune Vuorela wrote: On 2011-01-13, Felipe Sateler fsate...@debian.org wrote: We can't demand or require anyone to do anything. Yet we expect I think this is mostly wrong. We can demand or require people to step down. And we should if we don't think they do a proper job. I don't agree. First of all, we don't require people to step down, we hijack their packages (which means we force them to not do something). Second, we do that not when they are not doing a proper job, but when they actually block others from doing the proper job. -- Saludos, Felipe Sateler -- 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/igpk3k$inb$2...@dough.gmane.org
Re: Forwarding bugs upstream
On Fri, Jan 14, 2011 at 9:27 AM, Stefano Zacchiroli z...@debian.org wrote: On Fri, Jan 14, 2011 at 11:29:58AM +, Sune Vuorela wrote: We have written a bit about what's needed here: http://pkg-kde.alioth.debian.org/bugs.html A while ago I've reviewed a little bit which kind of contributions distros are looking for, from people who are willing to get involved with the distro (see #608400 for a corresponding goal). Most distros are looking for bug triager and providing specific documentation to train contributors in that direction. Historically in Debian we haven't looked for that, beside the very much understandable periodic cries for help from maintainers of popular package suites (GNOME, KDE, etc.). Maybe its time to generalize that? For instance, it seems to me that most of the above documentation by the KDE team is general and can be used to document a general bug triaging task on our how to contribute pages? Looking on wiki.d.o and www.d.o we don't seem to have much (any?) of it. If it's worth anything, that same document + the help from the Qt/KDE team helped me a lot to understand the workflow for bug triaging. Understanding the technical part was not difficult, but the workflow tends to be the the most obscure part. +1 for a general doc for that. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ -- 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/AANLkTikoCgu1-PPnmTYGz+Jh0TsU-g9=wej4zxie4...@mail.gmail.com
Re: Forwarding bugs upstream
John Goerzen dijo [Thu, Jan 13, 2011 at 05:08:26PM -0600]: So let's run out your scenario a bit: upstream asks user to test with upstream version X. Bug isn't reproducible by maintainer. Does the maintainer now have to provide user with binaries? This gets complicated when packaging isn't ready for the version in question, when the user has an arch the maintainer doesn't, etc. Often, users with not-so-mainstream architectures will have better technical understanding and more ability to help following up a report. -- 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/20110114152919.ga7...@gwolf.org
Re: Forwarding bugs upstream
On 01/13/2011 06:19 PM, Jesús M. Navarro wrote: Hi, Sune: On Thursday 13 January 2011 00:12:06 Sune Vuorela wrote: On 2011-01-12, Jesús M. Navarrojesus.nava...@undominio.net wrote: I have considered to take this one step further. Close bugs reported in Debian BTS with a severity of important or less that is a bug that should primarily be fixed upstream. Will this mean that the problem will somehow disappear from Debian? Because if it's a problem detected within Debian it's my feeling that it will have to be tracked within Debian till the problem is in Debian no more. No. but it is a way to be honest about teh issue: We are not spending debian time on fixing it. Then tag is as such. It is quite good to be honest: if you are not going to deal with it, plainly say so, no problem. But *don't* close them as long as the problem is still there. I think it is a huge waste of time to expect DDs to go through 400 bugs just to see if the problem is still there. Just close them outright. It is no better to have bugs tagged wontfix that are really fixed than to have bugs closed in our BTS and filed upstream. - John -- 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/4d30707e.1040...@complete.org
Re: Forwarding bugs upstream
Hi, John: On Friday 14 January 2011 16:49:18 John Goerzen wrote: [...] I think it is a huge waste of time to expect DDs to go through 400 bugs just to see if the problem is still there. Just close them outright. Why the package(s) got 400 bugs to start with? If the problem is there, then it's there. If somebody opened the bug then there was a bug at least on his opinion which nobody challenged. If there was a bug, then it need to be supposed that it will be there till there exists clear indication on the contrary. Anything else is awful practice. It is no better to have bugs tagged wontfix that are really fixed than to have bugs closed in our BTS and filed upstream. It's no better? It's probably orders of magnitude better (basically as the ratio between Debian users versus Debian developers). What are the chances of me looking for info about a bug I'm not suffering (because it's already fixed)? I'd bet nil, so that's the effect of a still opened -but already corrected bug. But if I'm suffering a bug and it's already declared on Debian's bug database I want to know and it'll save not only my time but that of any other people that will certainly suffer it if I know what to expect about it. Even you, as a Debian developer want to avoid me and others like me to open duplicate bugs. Cheers. -- 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/201101150040.39563.jesus.nava...@undominio.net
Re: Forwarding bugs upstream
Jesús M. Navarro jesus.nava...@undominio.net writes: Why the package(s) got 400 bugs to start with? If the problem is there, then it's there. If somebody opened the bug then there was a bug at least on his opinion which nobody challenged. If there was a bug, then it need to be supposed that it will be there till there exists clear indication on the contrary. Anything else is awful practice. I would argue that by the time the package reaches several thousand open bugs, all of which are some random mix of upstream, fixed, unreproducible, packaging, and incomplete reports, the BTS has become essentially unusable for everyone. The maintainers rarely have time to go back and look at those thousands of bugs in any meaningful way, and users are not going to be able to reasonably search through that many bugs to see if any of them are the problem that they're running into. At that point, the BTS is about as useful as a mailing list archive and the only chance that anything in there is going to be helpful is if Google happens to index it. In my personal experience, generally at that point the mailing list archive of wherever the bugs were originally sent is actually *more* useful since it's better-indexed. I think we have a significant failure mode here with packages that get large numbers of bugs. The BTS becomes pretty much unusable without very active triaging for those packages. And this is not a Debian-specific problem; for example, it's essentially impossible to extract any useful information from the Ubuntu nvidia-graphics-drivers bug page, and it only has 350 bugs. (Launchpad is, in my experience, worse than the Debian BTS at handling large bug volumes and becomes unusable faster.) There are a lot of things that have been said on this thread that I completely agree with for the average Debian package that gets a handful of bugs a month and doesn't have more than 50-100 bugs open at a time. I think most of the people commenting here have dealt primarily with those sorts of packages, and that's the experience in which the comments are grounded. Packages with thousands of bugs are another world, and while I agree with the drawbacks of aggressive bug triaging, I think aggressive bug triaging is still a better approach than letting the BTS page become a junk pile of abandoned reports no one is ever going to look at again. Obviously, the ideal is to have teams that scale with the incoming bug count for the package, who will stay on top of all those bugs and categorize them appropriately and ping unreproducible bugs, forward upstream bugs, and do all the great things that make the world a better place. But in the world in which we live, that manpower simply doesn't exist. If wishes were horses, beggars would ride. We have to apply strategies that are realistic given the manpower that we actually have, not the manpower that we wish we had. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87vd1rt4i0@windlord.stanford.edu
Re: Forwarding bugs upstream
On Thu, Jan 13, 2011 at 10:59:40AM +1100, Ben Finney wrote: Russ Allbery r...@debian.org writes: I really like Russ Allbery's sane words about this topic. To argue that is *not* to require or demand that anyone do any work, nor to strip anyone of their role. I wish I knew how to avert the seemingly inevitable charges of that which arise any time we discuss what the maintainer role entails. I understood the maintainer role as a set of tasks. Mediating between upstream and user is one part of this task and forewarding bugs belongs to this mediation. However, real life has turned out that we can not handle all our tasks with the same priority. If there is a conflict in the priorisation usually some common sense should be applied. I consider it common sense to *kindly* ask the bug reporter whether he feels able to help me in doing one of my tasks to foreward the bug to upstream himself. Common sense also applies when deciding whether the bug reporter seems to be competent enough to do this himself. Usually the bug report itself will tell the maintainer whether the reporter will be able to handle it himself (in case of a detailed bug report with reasonable information), whether the reporter needs extra advise (= is not able to do the work and I as the maintainer need to do the forewarding myself or at least enrich the report with extra information) or whatever reasonable action. In short: The Debian maintainer is responsible that a bug will be reported upstream. I don't see a problem if he delegates the actual work to somebody else who is able and willing to do the job (but please be nice to the user when asking for this kind of help). Free software lives from cooperation. Kind regards Andreas. -- http://fam-tille.de -- 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/20110113081935.ga24...@an3as.eu
Re: Forwarding bugs upstream
On 2011-01-13, Felipe Sateler fsate...@debian.org wrote: We can't demand or require anyone to do anything. Yet we expect I think this is mostly wrong. We can demand or require people to step down. And we should if we don't think they do a proper job. Now we just need to define what a proper job is. /Sune -- 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/slrniitkrv.rvp.nos...@sshway.ssh.pusling.com
Re: Forwarding bugs upstream
On Thu, Jan 13, 2011 at 11:27 AM, Sune Vuorela nos...@vuorela.dk wrote: On 2011-01-13, Felipe Sateler fsate...@debian.org wrote: We can't demand or require anyone to do anything. Yet we expect I think this is mostly wrong. We can demand or require people to step down. And we should if we don't think they do a proper job. Now we just need to define what a proper job is. Instead of stepping down, it might be better to ask for a co-maintainer. Olaf -- 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/AANLkTi=ga+ve+kqy0ksar6dhbqvs8wnykoux8cplf...@mail.gmail.com
Re: Forwarding bugs upstream
* Ian Jackson ijack...@chiark.greenend.org.uk [110113 01:54]: We can't demand or require anyone to do anything. Yet we expect maintainers to answer bug reports, provide packages, etc. The fact that you can't force anyone to do anything doesn't mean you can't say that some behavior is preferred or considered best practice. Yes. But in this case I don't think we should be expecting maintainers to necessarily shepherd bug reports upstream. I don't think a maintainer who fails to do so is failing in their job as maintainer. The maintainer should decide whether they think doing that is a useful thing to be doing for that package or that bug, and communicate this decision to the user (and set the bug state accordingly). The maintainer should of course assess where their work is best invested and act accordingly. But a package where bug reports to Debian are not properly handled or users are required[1] to report them elsewhere is definitely not fully well maintained. There is no point in trying to do things you miss the workforce to do and being honest about that is better than just piling up work. But there is also no point in redefining success. If there are not enough helping hands to get everything done, prioritising work properly is doing the work as good as we possibly can, it is not doing it good. Bernhard R. Link [1] There is nothing wrong with suggesting people to also report them upstream, especially in cases where the kind of the bug would make it likely that a direct interaction would generate more benefit for upstream. But this is a favor we ask from the bug reporter here so the request should be worded like that. -- 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/20110113112712.ga2...@pcpool00.mathematik.uni-freiburg.de
Re: Forwarding bugs upstream
Bernhard R. Link writes (Re: Forwarding bugs upstream): The maintainer should of course assess where their work is best invested and act accordingly. But a package where bug reports to Debian are not properly handled or users are required[1] to report them elsewhere is definitely not fully well maintained. I don't think this is true. I guess we'll just have to agree to disagree. Ian. -- 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/19758.61789.464204.627...@chiark.greenend.org.uk
Re: Forwarding bugs upstream
Ben Finney writes (Re: Forwarding bugs upstream): Ian Jackson ijack...@chiark.greenend.org.uk writes: But if a maintainer tells me please go and talk to them yourself or even please stop filing these kind of upstream bugs in Debian - you know how to do it yourself upstream and I have enough to do already then that's a wish I would respect. As would I; but, as stated earlier, often the only way I can feasibly respect such a wish is not to report such bugs at all. Perhaps so. In that case those bugs won't get reported. That's fine. If I and the maintainer both think that it's not worth our own time fighting upstream's bug system or ornery maintainers or disorganised email swamp or whatever, then we should go and do something else more useful - and less frustrating! From a purely optimisation point of view I can see the argument that maintainers have an advantage in dealing with upstream, because of the costs of getting to know how things work, setting up accounts, etc. But on the other hand as a rule of thumb the maintainer's time is more scarce than that of an individual bug submitter. So a tradeoff which saves maintainer time, even at the cost of a bigger amount of of submitters' time, can well be sensible. Remember: there is no shortage of bug reports. Ian. -- 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/19758.62160.464372.576...@chiark.greenend.org.uk
Re: Forwarding bugs upstream
On Thu, Jan 13, 2011 at 1:40 PM, Ian Jackson ijack...@chiark.greenend.org.uk wrote: Remember: there is no shortage of bug reports. That's unfortunately true. Why is it that bug squashing parties only happen a short time before release while it appears that the rest of the time the issue is ignored? -- Olaf -- 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/AANLkTi=kvzedjaa38+yhcpegw1ocaaad0fchgxkur...@mail.gmail.com
Re: Forwarding bugs upstream
On Thu, Jan 13, 2011 at 02:03:07PM +0100, Olaf van der Spek wrote:
Remember: there is no shortage of bug reports.
That's unfortunately true. Why is it that bug squashing parties only
happen a short time before release while it appears that the rest of
the time the issue is ignored?
Please, don't indulge toward trolling :-). There is no cabal^Wsecret
power in Debian who decides when to organize things and when to not
organize them.
BSP can be organized whenever you want but, as a matter of fact, they
get organized only when somebody volunteer to do that. If you want to
have a BSP, say, the 1st day after the release of Squeeze, you just have
to organize one. For packages that drown into bug *reports* due to
their popularity, you might also want to organize specific *triaging*
campaigns (better if in coordination with maintainers); they will
relieve the burden of maintainers in doing triaging and let them focus
on actual bugs that random BSP-participants might not feel entitled to
fix.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams
signature.asc
Description: Digital signature
Re: Forwarding bugs upstream
On Thu, Jan 13, 2011 at 2:25 PM, Stefano Zacchiroli z...@debian.org wrote: On Thu, Jan 13, 2011 at 02:03:07PM +0100, Olaf van der Spek wrote: Remember: there is no shortage of bug reports. That's unfortunately true. Why is it that bug squashing parties only happen a short time before release while it appears that the rest of the time the issue is ignored? Please, don't indulge toward trolling :-). There is no cabal^Wsecret power in Debian who decides when to organize things and when to not organize them. It's about improving quality, not about trolling. BSP can be organized whenever you want but, as a matter of fact, they get organized only when somebody volunteer to do that. If you want to have a BSP, say, the 1st day after the release of Squeeze, you just have to organize one. For packages that drown into bug *reports* due to their popularity, you might also want to organize specific *triaging* campaigns (better if in coordination with maintainers); they will relieve the burden of maintainers in doing triaging and let them focus on actual bugs that random BSP-participants might not feel entitled to fix. The point is focus on solving bugs shouldn't be limited to BSPs and the end of the release cycle. Olaf -- 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/AANLkTinfL++na7Ra0aKaHm-ZDAKvx1gaua1ErF==k...@mail.gmail.com
Re: Forwarding bugs upstream
Sune Vuorela nos...@vuorela.dk writes: Currently, the debian Qt/KDE team has around 800 open, non-forwarded bugs reported against their packages. I would guess that maybe 20 of them is packaging issues. But we can't find them. The rest of the bugs (780 open-non forwarded (and 300 forwarded)) is pure upstream issues. Ubuntu has a team (Bug Squad[1]) that tries to triage incoming bug reports, including forwarding them upstream when applicable. I don't know how successful this is, but if it has success, then maybe we could try to recruit volunteers for a similar team in Debian as well? This should of course include mentoring them a bit as well. Regards, Ansgar [1] https://wiki.ubuntu.com/BugSquad -- 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/87aaj46hko@marvin.43-1.org
Re: Forwarding bugs upstream
On Thu, 13 Jan 2011, Ben Finney wrote: But if they do refuse, then to what extent is that person accomplishing the maintainer role? To the greatest extent they can, which is what all of us do. I don't believe any maintainer is going to stand in the way of anyone who wants to help triage their bugs and manage reporting them upstream. I believe everyone thinks that having any bugs which are not personally handled is suboptimal, but we are limited by person-hours; every maintainer that I have personally spoken to about this issue who has to ask for users to forward the bugs themselves would gladly accept assistance from someone to do it for them. I personally would love to see patches to the BTS to enable forwarding these kinds of bug reports to upstreams more easily and integrate everything tightly with the BTS. Unfortunately, I am perpetually short of time to implement them myself, as excellent as I am certain they would be. Don Armstrong -- All my dreams came true. I just didn't think them through. -- a softer world #388 http://www.asofterworld.com/index.php?id=388 http://www.donarmstrong.com http://rzlab.ucr.edu -- 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/2011011303.gk5...@teltox.donarmstrong.com
Re: Forwarding bugs upstream
Don Armstrong writes (Re: Forwarding bugs upstream): I personally would love to see patches to the BTS to enable forwarding these kinds of bug reports to upstreams more easily and integrate everything tightly with the BTS. Unfortunately, I am perpetually short of time to implement them myself, as excellent as I am certain they would be. That would be a very nice feature for our BTS to have. BUT any such feature should only be enabled with respect to an upstream BTS after discussion with and approval from the relevant upstream. As we can see from this and previous discussions: how easy to make it to file bugs, who can file them, how they get to be filed, and so on, are things that people care about and have strong opinions about. Different projects have different cultural and technical expectations. Anecdote: while I was employed by Canonical I had to dissuade some of my colleagues from implementing and deploying, without consent from Debian, a feature in Launchpad that would automatically file corresponding bug reports in the Debian BTS. I expressed the view that doing so would be considered abuse by the Debian BTS admins and would probably result in some emergency ad-hoc wholesale blocking of Launchpad's access to Debian infrastructure. Not to mention an absolutely enormous flamewar. To all of us that would obviously have been a really bad idea. Let us be careful not to do to our upstreams what we don't want our downstreams to do to us. Ian. -- 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/19759.4171.832216.535...@chiark.greenend.org.uk
Re: Forwarding bugs upstream
Olaf van der Spek writes (Re: Forwarding bugs upstream): The point is focus on solving bugs shouldn't be limited to BSPs and the end of the release cycle. No, Stefano's point was that if you want something done, you should go and do it rather than whining here that it isn't being done. Ian. -- 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/19759.4204.880391.99...@chiark.greenend.org.uk
Re: Forwarding bugs upstream
On Thu, 13 Jan 2011, Olaf van der Spek wrote: The point is focus on solving bugs shouldn't be limited to BSPs and the end of the release cycle. It never is restricted to just those times; it just becomes more important as we get closer and closer to release. Don Armstrong -- This isn't life in the fast lane, it's life in the oncoming traffic -- Terry Pratchett http://www.donarmstrong.com http://rzlab.ucr.edu -- 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/20110113151101.go5...@teltox.donarmstrong.com
Re: Forwarding bugs upstream
Ansgar Burchardt writes (Re: Forwarding bugs upstream): Ubuntu has a team (Bug Squad[1]) that tries to triage incoming bug reports, including forwarding them upstream when applicable. I don't know how successful this is, but if it has success, then maybe we could try to recruit volunteers for a similar team in Debian as well? This should of course include mentoring them a bit as well. Ubuntu on the whole has more of a problem with large numbers of poor-quality bug reports than Debian, but there are certainly serious problems in some parts of Debian that less-skilled triagers will be able to help with. Overall I think the Ubuntu approach was helpful while I was there. Perhaps some people who have more substantial current involvement with Ubuntu can comment in more detail. What I saw was that less-skilled triagers have a tendency to: * make more mistakes than a maintainer will * overall, between them, have more effort than maintainers so it can be difficult to correct these mistakes * copy each other in a way that can make undesirable memes and particular undesirable behaviours spread and then be very hard to stamp out * apply fixed rules to situations rather than trying to rely on judgement (and anyway their judgement might be poor) which in the worst case can make them seem robotic * apply approaches out of their appropriate context - eg aggressively triage bugs for packages which don't have a bug flood problem or interfere with bugs filed by developers * behave as if bug reports are a bad thing and the idea is to close as many as possible (the opposite problem from the other common meme which is that bug reports are a good thing and we should try to get users to file as many as possible) I think many of these things could be dealt with by better education and mentoring, if we could find some people to do that mentoring and oversight of bug-squad style triagers. Debian would also have the problem that Debian maintainers are generally a lot more prickly than Ubuntu maintainers. Ubuntu tries very hard to be approachable; this has advantages and disadvantages but in the context of a bug squad Debian will also have the risk that bug squad members will get flamed and thus discouraged over small mistakes. Ian. -- 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/19759.4746.747018.61...@chiark.greenend.org.uk
Re: Forwarding bugs upstream
Zitat von Ansgar Burchardt ans...@debian.org: Sune Vuorela nos...@vuorela.dk writes: Currently, the debian Qt/KDE team has around 800 open, non-forwarded bugs reported against their packages. I would guess that maybe 20 of them is packaging issues. But we can't find them. The rest of the bugs (780 open-non forwarded (and 300 forwarded)) is pure upstream issues. Ubuntu has a team (Bug Squad[1]) that tries to triage incoming bug reports, including forwarding them upstream when applicable. I don't know how successful this is, but if it has success, then maybe we could try to recruit volunteers for a similar team in Debian as well? This should of course include mentoring them a bit as well. I've some bug reports for Ubuntu for my software that are _clearly_ not related to it. It just happens to match the key words in its name. So I don't think that I would call it successful :-/ HS -- 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/20110113153311.42747ifnb156j...@v1539.ncsrv.de
Re: Forwarding bugs upstream
On 01/12/2011 09:35 AM, Gunnar Wolf wrote: Ben Finney dijo [Wed, Jan 12, 2011 at 04:01:46PM +1100]: (...) I'm adding zero value here. Zero. It is a huge and frustrating waste of my time. Not in my view. I appreciate the Debian package maintainer acting in the interest of “lower the barrier for each Debian user of this package to report useful bug information”. To be clear: Thank you for the time you spend doing this, and the same to any other Debian maintainer who does unromantic work to keep the good information flowing. You are clearly adding value, you will probably word the user's request in a better way, you will know the library versions and settings the package was compiled with, the way it is installed, etc. You will probably forward only some relevant bits - We as package maintainers should bridge between a nontechnical user and the upstream developers. Of course, if your bug report was initially submitted by a Those are some valid points, probably more valid for many packages than Bacula (for reasons I'll get into later). But still, let's say that a Debian developer has X minutes to spend on Debian a day. What kinds of tasks that the developer does will add the most value to Free Software or benefit the most people to the greatest degree? * Working on Debian packaging * Fixing bugs that are within their scope/ability * Working on documentation * Cut-and-paste monkey with upstream BTSs I suggest that the last item provides the least value. If we realize that it is displacing time that Debian developers could be spending on things that benefit Free Software more, and frankly they are likely to enjoy more, it's a disturbing picture. Some of what you've suggested above could be accomplished by the DD telling the user, Here, include this info in your bug report and get me back in the loop if you need me. This is a special case of more general communication problems. It is rarely a good idea to have a gatekeeper in place between people that are capable of communicating already. If the user is not capable of producing cogent answers and a useful bug report, even when asked for specific details, this user is unlikely to produce a useful bug report for upstream. But the user is also unlikely to produce a useful bug report for Debian. I don't see my task as a maintainer to provide education to the user on how to read standard logfiles, use the command line (when relevant), etc. This is a particular problem with Bacula. There are many users that are unable to distinguish between a configuration mistake or misunderstanding on their part and a bug. I imagine this phenomenon exists in any sufficiently complex package that takes users out of their existing comfort zone. If it's clear to me that it's not a bug, I'll of course close it and point them to the Bacula users mailing list. Sometimes it is unclear immediately whether they have discovered a bug or not, but it is quite clear that they don't understand how to configure Bacula and would need a tremendous amount of handholding to get to the point where we know if there's even a bug or not. Again I try to push these to bacula-users. If someone asks me a question I know the answer to off the top of my head, I'll answer, but I never promised to provide free tech support by maintaining Bacula ;-) -- John -- 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/4d2f43b7.6070...@complete.org
Re: Forwarding bugs upstream
Olaf van der Spek olafvds...@gmail.com writes: That's unfortunately true. Why is it that bug squashing parties only happen a short time before release while it appears that the rest of the time the issue is ignored? This didn't happen during this release cycle, at least from my perspective. I remember lots of bug-squashing parties early on in squeeze's development. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87lj2ocyaj@windlord.stanford.edu
Re: Forwarding bugs upstream
John Goerzen jgoer...@complete.org writes: On 01/12/2011 09:35 AM, Gunnar Wolf wrote: You are clearly adding value [… enumeration of many ways the maintainer adds significant value by relaying bug report discussions …] Those are some valid points, probably more valid for many packages than Bacula (for reasons I'll get into later). But still, let's say that a Debian developer has X minutes to spend on Debian a day. What kinds of tasks that the developer does will add the most value to Free Software or benefit the most people to the greatest degree? That issue (use of limited resources) is of course important, and I appreciate that it is sub-optimal to have skilled maintainers spend limited resources on what feels like mechanical work. I would ask, though, that this description: * Cut-and-paste monkey with upstream BTSs be amended, even if only in the maintainer's mental description of the task, in light of the points raised by Gunnar and others about the value added by the maintainer relaying information from the user. It's usually more valuable than merely cut-and-paste monkey, and realising that may help it feel (a little?) less frustrating. I suggest that the last item provides the least value. Of the items you listed, I agree that yes, relaying bug report information is often low in terms of value added. But it does add significant value in more cases than not. At the least, it adds the value that, if it gets to the point where such a decision needs to be made, a significant proportion of such valid bug reports would not otherwise be reported upstream at all. So, thank you to any maintainer who does this work, and I hope this thread helps it happen more by making clearer the value maintainers are adding when they do so. -- \ “Yesterday I parked my car in a tow-away zone. When I came back | `\ the entire area was missing.” —Steven Wright | _o__) | Ben Finney -- 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/87tyhca4vs@benfinney.id.au
Re: Forwarding bugs upstream
On Thu, Jan 13, 2011 at 02:46:35PM +, Ian Jackson wrote:
Anecdote: while I was employed by Canonical I had to dissuade some of
my colleagues from implementing and deploying, without consent from
Debian, a feature in Launchpad that would automatically file
corresponding bug reports in the Debian BTS. I expressed the view
that doing so would be considered abuse by the Debian BTS admins and
would probably result in some emergency ad-hoc wholesale blocking of
Launchpad's access to Debian infrastructure. Not to mention an
absolutely enormous flamewar.
To all of us that would obviously have been a really bad idea.
Let us be careful not to do to our upstreams what we don't want our
downstreams to do to us.
Right, it's a sane principle.
By the same principle, I'm sure that we in Debian would not appreciate
if Ubuntu developers would ask their users to submit _packaging_ bugs to
Debian no matter what, instead of filing them to Launchpad first. By
doing so, they would risk that a bug apparently due to Debian is in fact
induced---in some non obvious [1] way---by some other Ubuntu change.
The example can easily be transposed from the Ubuntu-Debian border to
the Debian-Upstream border. If we ask users to submit bug report
upstream no matter what, we risk of upsetting upstreams if, repeatedly,
they'll start getting bug reports which users believe to be upstream
whereas they are Debian's fault, in some non obvious way.
The only conclusions I can make from the above are:
a) Getting upset for *specific* bug reports is pointless: there are
always going to be bug reports filed at wrong targets which are
someone-else's fault. Getting upset for them won't make them less
likely in the future and will just worsen relationships between the
corresponding upstream (resp. downstream). The best we can do is
devise practices that reduce the *overall* risk of shooting bugs at
the wrong target.
b) To reduce that risk, the best we can do is teach users guidelines
about where to report bugs. The driving principle could be something
like:
if you feel confident in judging that and if you think the bug
belongs upstream then please report it upstream directly; doing
otherwise will just increase communication overhead
Note that our *current* policy [2] is exactly dual to that; we
explicitly ask users to report the bug to Debian even if the user
thinks it belong upstream. Clearly, the current policy err on the
cautious side; this thread might lead to consensus in empowering
users more with that decision. (Then, if we reach it, we should
document it properly in various places, including that page and
reportbug---discussing it only among devs without informing users
will be quite useless.)
Note that, even with that policy, there will be users reporting to
Debian (because they don't read the doc, because they don't know how
to report upstream, because they can't make the judgement, etc.).
Cheers.
[1] obvious here is in user's opinion, as when a bug report is filed
there are only users who can judge that
[2] http://www.debian.org/Bugs/Reporting
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams
signature.asc
Description: Digital signature
Re: Forwarding bugs upstream
On 01/12/2011 05:59 PM, Ben Finney wrote: Rather, I'm arguing that the maintainer role, as a mediator and interface between upstream and the Debian user, entails a whole lot of different tasks, and being a mediator in the discussion between upstream-who-doesn't-care-about-Debian-specifically and Debian-user-with-a-bug-report is part of that role. That's a good point, and I actually agree with that. But I (think) I disagree on how it necessarily is implemented. In other words, I would be happy to point the submitter to the upstream BTS, send them a paragraph to cut and paste into their report that contains anything relevant from the Debian perspective, and leave them with a promise to be willing to get involved should anyone think I need to be. That part does add value. Copying and pasting conversations back and forth doesn't. - John -- 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/4d2f83d1.4070...@complete.org
Re: Forwarding bugs upstream
On 01/12/2011 12:52 AM, Nikita V. Youshchenko wrote: I understand that maintainers' time is limited and that forwarding bugs is not an enjoyable task. But I also understand that having a BTS account for the upstream BTS of each of the 2405 packages I have installed on my laptop (not to mention my other machines) is simply not practical. I also don't have the benefit of the rapport that a maintainer has with upstream and knowledge of upstream practices. Upstream tend to request users to install latest and greatest versions, often for source or using other unsafe methods. Not only for package in question but also for explicit and implicit dependences. Non-technical follow these broken advices and break their systems. And then complain that Debian is problematic for them. Not all upstreams are like that, but I think that brings to the front an important point: there are vast differences in users, in upstreams, and in maintainers. So let's run out your scenario a bit: upstream asks user to test with upstream version X. Bug isn't reproducible by maintainer. Does the maintainer now have to provide user with binaries? This gets complicated when packaging isn't ready for the version in question, when the user has an arch the maintainer doesn't, etc. -- John -- 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/4d2f85ea.1050...@complete.org
Re: Forwarding bugs upstream
Hi, Sune: On Thursday 13 January 2011 00:12:06 Sune Vuorela wrote: On 2011-01-12, Jesús M. Navarro jesus.nava...@undominio.net wrote: I have considered to take this one step further. Close bugs reported in Debian BTS with a severity of important or less that is a bug that should primarily be fixed upstream. Will this mean that the problem will somehow disappear from Debian? Because if it's a problem detected within Debian it's my feeling that it will have to be tracked within Debian till the problem is in Debian no more. No. but it is a way to be honest about teh issue: We are not spending debian time on fixing it. Then tag is as such. It is quite good to be honest: if you are not going to deal with it, plainly say so, no problem. But *don't* close them as long as the problem is still there. Currently, the debian Qt/KDE team has around 800 open, non-forwarded bugs reported against their packages. I would guess that maybe 20 of them is packaging issues. But we can't find them. Start one at a time. With more bugs arriving than we are able to close? Start one at a time. Your end-year bonus won't suffer if your Debian's bug queue is longer by then, will it? If your problem is too short of a workforce don't be ashamed of it and be honest enough for the bug queue to grow as it should. 4) It's not my problem that you lack the time, really. And no, that you are not paid for it it's no excuse either. Maybe it's that you lack the time for the *boring* side of the task or maybe it's that you really don't have the time. In the first case resign as a debian maintainer; in the second one orphan the package. Debian is proud to Dear Jesus. Are you seriously saying that - the kernel mainatiners should step down - the xorg maintainers should step down - the mozilla maintainers should step down - the gnome maintainers should step down - the kde maintainers should step down - the xfce maintainers should step down - the openoffice/libre office maintainers should step down If they are not ready to take over their shoulders what it takes to do it properly, undoubtly yes. If that means that Debian project becomes irrelevant so be it because gaming the statistics for the project to look what it in fact is not, already means exactly the same only it deludes it users... for a while. Please pay attention that I said *if*. That doesn't mean neither an endorsement nor a beliveness from my side that that's current situation (I'm far of thinking so, in fact, or else I wouldn't be expending my time here). And who do you think should step up ? Not my problem. Sorry if I sound harsh but please think about it coldly and you'll see that's in fact the proper response: if nobody is really up to the task, then the task should be abandoned. (This message sounded much more negative than both my mood and my real intention wanted to, but I found no other way to send the message I wanted to send. Sorry in advance). Cheers. -- 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/201101140119.22762.jesus.nava...@undominio.net
Re: Forwarding bugs upstream
Hi, John: On Thursday 13 January 2011 19:25:59 John Goerzen wrote: On 01/12/2011 09:35 AM, Gunnar Wolf wrote: [...] But still, let's say that a Debian developer has X minutes to spend on Debian a day. Let's be true: it's not that a Debian developer has X minutes to spend but that a Debian developer *wants* to spend X minutes. Probably same end result but wildly different motivations. What kinds of tasks that the developer does will add the most value to Free Software or benefit the most people to the greatest degree? * Working on Debian packaging * Fixing bugs that are within their scope/ability * Working on documentation * Cut-and-paste monkey with upstream BTSs Managing information, always managing information. Remember: information is power. First information, then everything else. In your proposed scope that means: 1) Working on *a* Debian packaging: Without *a* Debian package wouldn't be bugs for it, would it? But pay attention to the a within a package: it's of no value (worse than that: it's of negative value) working on new packages when the already packaged ones are not in good shape (I'll limit my scope to packages maintained by the same person: it seems to me that there are some Debian Maintainers -really and luckily a true minority of them, that seem to be trying to break a record in that they maintain a bazillion of them but when you look at those packages bug records they have bugs from back to the day Armstrong footed the Moon. That's of no good). 2) Cut-and-paste monkey with upstream BTSs (for those bugs worth to do it): that will allow for you to parallelize your effort and more bugs will be corrected in a given time. If any, bugs you (properly) pass to the upstream developer are bugs that will cost you not a dime of your valuable time from them on. 3) Working on documentation (including documenting which bugs are your working on, which bugs will be dealt with later and which bugs have a known workaround or you just won't even try to fix and why): properly informing about your intentions and the real state of your packages will reduce the rate that bugs come in and will relax your users so they'll be more kind to you... or at least, it will allow you to say RTFM (or RTF bug reports, or RTF FAQ) and be with it. 4) Fixing bugs that are within their scope/ability. I know this will seem quite counterintuitive but yes, fixing bugs is the lowest of your priorities. If you understand what I said, good; if you didn't, please, make me the honour of considering me as an authority and act accordingly (and by act accordingly I mean ala popperian, consider my reasonements as the less valuable of your knowledge chain but still valuable). Some of what you've suggested above could be accomplished by the DD telling the user, Here, include this info in your bug report and get me back in the loop if you need me. Regarding bugs, the first priority of a package maintainer should always be to be able to reproduce it and once he is able to reproduce it, taking the user out of the loop (except for timely informing him of his advances) till the bug is properly solutioned. This is a special case of more general communication problems. It is rarely a good idea to have a gatekeeper in place between people that are capable of communicating already. Once the package maintainer is able to reproduce the bug, odds are he will be the most capable one to properly care about it. If the user is not capable of producing cogent answers and a useful bug report, even when asked for specific details, this user is unlikely to produce a useful bug report for upstream. But the user is also unlikely to produce a useful bug report for Debian. Then, after proper time and effort you will find yourself in the position of honestly close it with a non-reproducible tag. I don't see my task as a maintainer to provide education to the user on how to read standard logfiles, use the command line (when relevant), etc. Why not? You want to provide Debian with good packages and the end user with valuable software, don't you? This is a particular problem with Bacula. There are many users that are unable to distinguish between a configuration mistake or misunderstanding on their part and a bug. I know your pain: being there, seen that, got the t-shirt. But you are in the great situation of being able to tell them RTFM without pain nor remorse. Do it as needed. I imagine this phenomenon exists in any sufficiently complex package that takes users out of their existing comfort zone. If it's clear to me that it's not a bug, I'll of course close it and point them to the Bacula users mailing list. That should be OK... once you tell the user out of all my knowlege it seems to be a configuration problem, please treat it accordingly. Sometimes it is unclear immediately whether they have discovered a bug or not, but it is quite clear that
Re: Forwarding bugs upstream
Hi, Andreas: On Thursday 13 January 2011 09:19:35 Andreas Tille wrote: [...] In short: The Debian maintainer is responsible that a bug will be reported upstream. I don't see a problem if he delegates the actual work to somebody else who is able and willing to do the job (but please be nice to the user when asking for this kind of help). Free software lives from cooperation. Utmost wisely spoken words. My felicitiation. Cheers. -- 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/201101140159.03674.jesus.nava...@undominio.net
Re: Forwarding bugs upstream
Andreas Tille andr...@an3as.eu writes: In short: The Debian maintainer is responsible that a bug will be reported upstream. I don't see a problem if he delegates the actual work to somebody else who is able and willing to do the job (but please be nice to the user when asking for this kind of help). Free software lives from cooperation. That's a good summary of my position too, and well put. Thank you. -- \ “Nature is trying very hard to make us succeed, but nature does | `\ not depend on us. We are not the only experiment.” —Richard | _o__) Buckminster Fuller, 1978-04-30 | Ben Finney -- 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/87y66o8b4s@benfinney.id.au
Re: Forwarding bugs upstream
On Mi, 12 ian 11, 10:55:34, Paul Wise wrote: On Wed, Jan 12, 2011 at 9:29 AM, Drake Wilson dr...@begriffli.ch wrote: Which upstream bug trackers, if any, would make the above not work? Sourceforge and probably Gforge/FusionForge trackers. The only tracker I'm aware of which would work is Trac, some instances of which allow anyone to put in anyone else's email address as the author of the bug. Would it be possible to subscribe the Debian bug instead and have the upstream tracker accept mail from the BTS? Regards, Andrei -- Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic signature.asc Description: Digital signature
Re: Forwarding bugs upstream
Le mardi 11 janvier 2011 à 23:54 +, brian m. carlson a écrit : I've noticed a trend lately that I am often asked to forward the bugs I report to the Debian BTS upstream, either by the maintainers or automatically by a bug script. I believe, and I continue to believe, that maintainers should forward bugs upstream instead of requiring (or strongly encouraging) users to do so. As soon as there are enough maintainers to do that, yes, that makes sense. Since for most large packages there are not, we are forced to do what we can. Skilled maintainers already spend way too much time only reading the flow of bug reports. That’s time not spent into packaging work and long-term improvement. We regularly ask newcomers to try and deal with bugs, but this boring and daunting task only serves to discourage them. Given that only a rough tenth of the bugs are actually useful, that’s the amount that can be either forwarded as is (knowing that the upstream maintainer will not ask for details the maintainer doesn’t have) or dealt with directly. If someone finds a way to reduce the noise, maybe what you suggest could become feasible. -- .''`. : :' : “You would need to ask a lawyer if you don't know `. `' that a handshake of course makes a valid contract.” `--- J???rg Schilling -- 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/1294821223.25195.68.ca...@meh
Re: Forwarding bugs upstream
* Drake Wilson dr...@begriffli.ch [2011-01-12 08:09] wrote: Quoth Paul Wise p...@debian.org, on 2011-01-12 10:55:34 +0800: [among other responses] Sourceforge and probably Gforge/FusionForge trackers. The only tracker I'm aware of which would work is Trac, some instances of which allow anyone to put in anyone else's email address as the author of the bug. So basically most or all of them, then. Right. This doesn't leave much in the way of good options: What about handling this on Debian side? So the maintainer will not register his/her personal account to upstream but package specific email alias. If email is received then BTS - will add it into the bugreport if pairing information is found (e.g. upstream ticket ID) - will forward to maintainer otherwise Antonin -- 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/20110112075111.ga3...@bobek.cz
Re: Forwarding bugs upstream
Drake Wilson, 2011-01-11 20:19:34 -0700 : [...] This doesn't leave much in the way of good options: - Having the user report bugs twice [...] - Having the maintainer be the reporter of record for upstream [...] - Having the maintainer forward the bug report but make the user the reporter In a mid-term future, there's another possibility. Forges and bug trackers have started thinking about, and implementing, infrastructure to allow distributed bug tracking. There are at least two efforts in that direction: - the “SD” approach, where people have one local interface that talks to possibly several remote trackers and syncs stuff around; SD already has bridges to several engines. - the “OSLC-CM” approach, where trackers implement a common API allowing creation and manipulation of reports with a machine-to-machine interface; this allows a single interface (think dashboard) to display and interact with bugs independently of their physical location. If one or the other approach ends up generally usable, then a new scenario emerges: - end-user reports bug on the Debian BTS (or the Fedora Bugzilla, or the Ubuntu Launchpad, or whatever it is Suse has); - distro maintainer does some tagging if they consider the bug to be upstream; - upstream has a handful of accounts on the distros' BTS, and they see the appropriately tagged bugs on their dashboard; they can interact with the user from there, and possibly clone the bug into their own local BTS. We still face a scalability problem, in that upstreams may need an account on each of the (major) distributions' BTS that require logins, but in the end both upstream and the end user can work on the same report. Whether that report is only on the distro's BTS or synced with upstream's BTS is something that time will tell. For reference, the OSLC-CM API is currently being implemented for FusionForge, and I'm told Mantis already has it. I seem to recall work was in progress for Bugzilla too, but I don't remember the details. On the GUI client side, work is happening in Eclipse and probably others. Roland. -- Roland Mas Indépendant en informatique libre -- Free software freelance http://www.gnurandal.com/ -- 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/8739oywkdx@mirexpress.internal.placard.fr.eu.org
Re: Forwarding bugs upstream
On 2011-01-11, brian m. carlson sand...@crustytoothpaste.net wrote: I've noticed a trend lately that I am often asked to forward the bugs I report to the Debian BTS upstream, either by the maintainers or automatically by a bug script. I believe, and I continue to believe, I have considered to take this one step further. Close bugs reported in Debian BTS with a severity of important or less that is a bug that should primarily be fixed upstream. Currently, the debian Qt/KDE team has around 800 open, non-forwarded bugs reported against their packages. I would guess that maybe 20 of them is packaging issues. But we can't find them. The rest of the bugs (780 open-non forwarded (and 300 forwarded)) is pure upstream issues. /Sune - who also don't think that being a manual email2webformandback proxy is a good idea. -- 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/slrniirb1r.rvp.nos...@sshway.ssh.pusling.com
Re: Forwarding bugs upstream
On Tue, Jan 11, 2011 at 09:15:41PM -0600, John Goerzen wrote: I think it is perfectly fine for a user to submit a bug report to the Debian BTS first. They may not always be equipped to know what is a Debian and what is an upstream bug. And I also think it ought to be perfectly valid for the Debian developer to close the bug saying it's an upstream issue, together with a pointer to the upstream BTS and promise to get involved should there be any question about the Debian packaging, environment, etc. I think this can actually increase the maintainer's burden, since it can increase the number of duplicate bug reports, since there isn't already a bug listed as reported. I generally assume that if a bug is open but not marked forwarded that it isn't forwarded, and I'm not intrinsically opposed to this. Forwarded bugs are better, but if it doesn't happen immediately, that's okay. Now, here's how it proceeds if I have to forward a bug upstream for Bacula, which uses Mantis. Creating a Mantis account takes 30 seconds, but Mantis won't email reports to people without accounts, and the only way to add stuff to it is on the web. As I've said, I generally don't mind being added to the CC list, and I think that BTS systems should allow non-subscribers (and subscribers) to add information via email. I realize that upstreams tend to use BTSes that don't do that and therefore make their end users go through a lot of unnecessary pain. Also, if the BTS won't CC me when someone responds to the bug (even with an account), there is zero chance of me reporting the bug upstream, since I have better things to do with my life than constantly checking a slew of BTSes. I'm adding zero value here. Zero. It is a huge and frustrating waste of my time. It is also frustrating for upstream, who would rather just talk with the user directly and involve me if they think there's a Debian-specific question. I don't understand why some users want it to go this way, but many clearly do despite the fact that they get worse service. I think it depends on the situation. I've looked at the open and forwarded bugs reported under this email address and of the 60, there are at least 47 that I could immediately determine (just by being reminded of the Subject line) that included a testcase or a patch or were trivially easy to reproduce (or understand wrt the desired feature for wishlist requests). Those are pretty much forward-and-forget. There are cases where the maintainer cannot appreciably reproduce the problem (such as with the kernel or X) and then I have to make a decision whether I want to put up with the bug or forward it upstream myself. In these cases, it's usually the former, since I am just not going to recompile my kernel (which is the Debian one) the ten times required to bisect the problem. If there's a new version in experimental, I will often try that to see if it solves the problem, though, and report back. I try to forward bugs upstream when I have the time, especially when I have a patch, since it may need tweaking with upstream. But I always try to put a patch in the Debian BTS, since it is much more likely to be rapidly fixed in that case. (#605941 is a great example of this.) So I think what my position is is this: if the bug is simple, clear, and easily understandable, then I don't think it's unreasonable for the maintainer to forward the bug upstream. Examples that I think fit into this category: * (normal) This program produces out-of-range results when I use the attached file as input and option -p. * (wishlist) This program should support W3C specification ABC (as well as the currently-supported DEF) with regard to XYZ functionality. If it's going to be difficult and require the user and upstream to work together to solve the problem, then it's okay to say something like, I can't reproduce this problem and upstream is not going to be able to fix it without your help, so would you mind forwarding the bug upstream? Giving a reason actually makes me much more likely to comply and less likely to be irritated. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Forwarding bugs upstream
Ben Finney dijo [Wed, Jan 12, 2011 at 04:01:46PM +1100]: (...) I'm adding zero value here. Zero. It is a huge and frustrating waste of my time. Not in my view. I appreciate the Debian package maintainer acting in the interest of “lower the barrier for each Debian user of this package to report useful bug information”. To be clear: Thank you for the time you spend doing this, and the same to any other Debian maintainer who does unromantic work to keep the good information flowing. You are clearly adding value, you will probably word the user's request in a better way, you will know the library versions and settings the package was compiled with, the way it is installed, etc. You will probably forward only some relevant bits - We as package maintainers should bridge between a nontechnical user and the upstream developers. Of course, if your bug report was initially submitted by a technically knowledgeable user, it might be better just to point him to a bug report (already opened by you) in the upstream tracker. Also, when I forward a bug report, I quote the Debian BTS address for the upstream developers to be able to get the original (although I will mediate anyway). Of course, there is not just one kind of user or upstream. Some will appreciate to get more involved. Some users will sadly just say this is b0rken, you must fix it, you suck - But they are IMO not prevalent. Many upstreams will want users to use the latest versions, and it is our task to find how to fix/backport. Quite the opposite, from my position. A great feature of the Debian BTS is that any user can interact with it through a standard interface without maintaining multiple separate identities; heck, without having to create a single new identity at all. FWIW, I have been asked by users and upstreams whether they can interact with bug reports via a simpler interface, as they prefer not to use mail for it. Of course, it all depends on the person at hand. I agree it is good to have a unified, standarized interface for our users. And, of course, our BTS serves us (the Debian community) very well. -- 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/20110112153516.ga26...@gwolf.org
Re: Forwarding bugs upstream
John Goerzen writes (Re: Forwarding bugs upstream): I'm going to have a slightly different viewpoint on this. I agree with John, basically. I'm adding zero value here. Zero. [...] Some people have replied suggesting scenarios where the Debian maintainer is adding something. That's fine - in that case, the maintainer can do whatever is necessary to add that value. But I think this should be up to the Debian maintainer. Being a Debian maintainer should not mean agreeing to be a helpdesk or bug proxy. Ian. -- 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/19757.56337.388114.637...@chiark.greenend.org.uk
Re: Forwarding bugs upstream
brian m. carlson writes (Re: Forwarding bugs upstream): On Tue, Jan 11, 2011 at 09:15:41PM -0600, John Goerzen wrote: I think it is perfectly fine for a user to submit a bug report to the Debian BTS first. They may not always be equipped to know what is a Debian and what is an upstream bug. And I also think it ought to be perfectly valid for the Debian developer to close the bug saying it's an upstream issue, together with a pointer to the upstream BTS and promise to get involved should there be any question about the Debian packaging, environment, etc. I think this can actually increase the maintainer's burden, since it can increase the number of duplicate bug reports, [...] If the maintainer agrees with you then they will be happy to deal with the bug report the way you want. But I think this should be up to the maintainer to decide. As I've said, I generally don't mind being added to the CC list, and I think that BTS systems should allow non-subscribers (and subscribers) to add information via email. I realize that upstreams tend to use BTSes that don't do that and therefore make their end users go through a lot of unnecessary pain. Also, if the BTS won't CC me when someone responds to the bug (even with an account), there is zero chance of me reporting the bug upstream, since I have better things to do with my life than constantly checking a slew of BTSes. That is up to you. If you report the bug to the Debian BTS but neither you nor the Debian maintainer want to do the make-work of dealing with upstream's tedious BTS, then the bug will sit in Debian's BTS tagged should go upstream indefinitely. I don't think it is up to you to say that this is the maintainer's problem and that they must do something about it. If it bothers you, you should yourself do the work to improve matters. I think it depends on the situation. I've looked at the open and forwarded bugs reported under this email address and of the 60, there are at least 47 that I could immediately determine (just by being reminded of the Subject line) that included a testcase or a patch or were trivially easy to reproduce (or understand wrt the desired feature for wishlist requests). Those are pretty much forward-and-forget. If you think the work of forwarding bugs upstream is so important and useful - more important and useful than the work that you are currently doing - then perhaps you would like to take on that role for some existing maintainers who don't have the time, or who feel that it isn't tha valuable ? So I think what my position is is this: if the bug is simple, clear, and easily understandable, then I don't think it's unreasonable for the maintainer to forward the bug upstream. Examples that I think fit into this category: I think it is always reasonable for the maintainer to forward the bug upstream. But what I think is bad is _demanding_ or _requiring_ the maintainer to forward the bug upstream. If they don't want to do that for whatever reason then asking the submitter to do so is IMO perfectly acceptable. Ian. -- 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/19757.56664.836061.356...@chiark.greenend.org.uk
Re: Forwarding bugs upstream
On Wed, Jan 12, 2011 at 02:56:35PM +, brian m. carlson wrote: [...] Also, if the BTS won't CC me when someone responds to the bug (even with an account), there is zero chance of me reporting the bug upstream, since I have better things to do with my life than constantly checking a slew of BTSes. [...] The bts-link system takes care of polling for upstream bug status updates for several common bug trackers. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- 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/20110112172550.gu3...@decadent.org.uk
Re: Forwarding bugs upstream
Hi, Sune: On Wednesday 12 January 2011 14:27:23 Sune Vuorela wrote: On 2011-01-11, brian m. carlson sand...@crustytoothpaste.net wrote: I've noticed a trend lately that I am often asked to forward the bugs I report to the Debian BTS upstream, either by the maintainers or automatically by a bug script. I believe, and I continue to believe, I have considered to take this one step further. Close bugs reported in Debian BTS with a severity of important or less that is a bug that should primarily be fixed upstream. Will this mean that the problem will somehow disappear from Debian? Because if it's a problem detected within Debian it's my feeling that it will have to be tracked within Debian till the problem is in Debian no more. Currently, the debian Qt/KDE team has around 800 open, non-forwarded bugs reported against their packages. I would guess that maybe 20 of them is packaging issues. But we can't find them. Start one at a time. I've been both sides of the wall (as and end user and as being in charge of supporting some apps and environments) and here comes my opinion as a mere user with some hindsights. I'll try to make my points clear, so if someone finds them a bit harsh, please understand that it was not my intention, that my native language is not English and that my aim is mainly make myself as clear as possible: From the user point of view: 1) A known operational problem that is still there never should map to a closed bug, no matter what. That means that forwarded upstream, while it might be a valid bug state can't be one meaning closed. I'm having a problem so I'm looking at open problems in the bug database. That means that if there's a problem in, say, Lenny, even if it's demonstrably closed in Squeeze it should appear opened when I look for bugs in Lenny. 2) The maintainer took over his shoulders some responsibilities when he became maintainer. When I'm facing a problem with a package in the distribution, it's you the one that will have to cope with it. You'll take my data and you'll try to reproduce the bug. If you are able to reproduce the bug, then it's your problem from now on. If you can't you'll ask me for more data and will try to hint which data will be more valuable and will explain to me. 3) Corollary of two is that if you are able to reproduce the bug and you deem it to be an upstream one, you should be the one rising it to upstream and track it from them on, but since the problem is still there you shouldn't close the bug (see 1) but mark/tag it as an upstream problem and that you already are dealing with it with upstream at upstream's bug number. 4) It's not my problem that you lack the time, really. And no, that you are not paid for it it's no excuse either. Maybe it's that you lack the time for the *boring* side of the task or maybe it's that you really don't have the time. In the first case resign as a debian maintainer; in the second one orphan the package. Debian is proud to host a bazillion packages but I really appreciate much more 1/10th of a bazillion worth of properly maintained packages than a bazillion of half assed ones. In the first case I know exactly what the situation is, in the second I don't know if I'm lucky when I see foo already packaged for Debian or if foo will be one of the less than production-ready ones. It severely hinders the overall perception about the quality of the project. 5) I as a user should understand that you are not a magician; without enough data you won't be able to deal with my bug and you will have to close it as non-reproducible, if I don't feel that to be a good reason I always can go anywhere else (say, the upstream developer) to see if I'm more lucky there. 6) There will be (rare) cases when the debian maintainer really won't be in a position of being of help. Then I'll need to understand that, after all, it's me the one having a problem, not him, so it's in my best interest to take the time going upstream to see what can be done and make the debian maintainer (and other who might happen to look at the bug records) know about that. 7) Tracking bugs is always a burden so don't expect too much from somebody doing it for free. Try to be helpful since it's in your best interest, say thanks with open spirit and, please, take the time to introduce a workaround or the solution you found in the bug system so others can benefit out of it and the debian maintainer can dedicate his time to something more productive. From the maintainer point of view: 1) An unreproducible bug is an unexistant bug. It's valid for unexistant bugs not to show in an open bugs list so you are free to close them with a non-reproducible message. If nine out of ten bug reports lack enough data, ask for better data and advise that without new data you won't be able to reproduce the bug so it will be closed in a decent amount of time (say, two weeks? one month?) and then
Re: Forwarding bugs upstream
On 2011-01-12, Jesús M. Navarro jesus.nava...@undominio.net wrote: I have considered to take this one step further. Close bugs reported in Debian BTS with a severity of important or less that is a bug that should primarily be fixed upstream. Will this mean that the problem will somehow disappear from Debian? Because if it's a problem detected within Debian it's my feeling that it will have to be tracked within Debian till the problem is in Debian no more. No. but it is a way to be honest about teh issue: We are not spending debian time on fixing it. Currently, the debian Qt/KDE team has around 800 open, non-forwarded bugs reported against their packages. I would guess that maybe 20 of them is packaging issues. But we can't find them. Start one at a time. With more bugs arriving than we are able to close? 4) It's not my problem that you lack the time, really. And no, that you are not paid for it it's no excuse either. Maybe it's that you lack the time for the *boring* side of the task or maybe it's that you really don't have the time. In the first case resign as a debian maintainer; in the second one orphan the package. Debian is proud to Dear Jesus. Are you seriously saying that - the kernel mainatiners should step down - the xorg maintainers should step down - the mozilla maintainers should step down - the gnome maintainers should step down - the kde maintainers should step down - the xfce maintainers should step down - the openoffice/libre office maintainers should step down - ... And who do you think should step up ? /Sune -- 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/slrniisda6.rvp.nos...@sshway.ssh.pusling.com
Re: Forwarding bugs upstream
Ian Jackson ijack...@chiark.greenend.org.uk writes: I think it is always reasonable for the maintainer to forward the bug upstream. But what I think is bad is _demanding_ or _requiring_ the maintainer to forward the bug upstream. If they don't want to do that for whatever reason then asking the submitter to do so is IMO perfectly acceptable. Indeed, the Debian project can't demand or require any work of anyone. I think it's perfectly acceptable for any such volunteer to refuse to do the work. But if they do refuse, then to what extent is that person accomplishing the maintainer role? -- \ “All progress has resulted from people who took unpopular | `\ positions.” —Adlai Stevenson | _o__) | Ben Finney -- 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/87fwsxd86t@benfinney.id.au
Re: Forwarding bugs upstream
On Thu, Jan 13, 2011 at 12:12 AM, Sune Vuorela nos...@vuorela.dk wrote: Will this mean that the problem will somehow disappear from Debian? Because if it's a problem detected within Debian it's my feeling that it will have to be tracked within Debian till the problem is in Debian no more. No. but it is a way to be honest about teh issue: We are not spending debian time on fixing it. That's better than no response to a bug report at all. Olaf -- 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/aanlkti=iivsnrccew4v_p-c_faho6arofrgfdbt8=...@mail.gmail.com
Re: Forwarding bugs upstream
Ben Finney ben+deb...@benfinney.id.au writes: Indeed, the Debian project can't demand or require any work of anyone. I think it's perfectly acceptable for any such volunteer to refuse to do the work. But if they do refuse, then to what extent is that person accomplishing the maintainer role? I feel like it's rare for any of us, and I'm definitely including myself, to completely accomplish the maintainer role. There's always more work that I could be doing: bugs that are still open, things that could be improved, project-wide updates that need attention, etc. While it's useful to have an idea of that to-do list, I'm not sure it's useful to beat oneself or others up about not completely accomplishing everything we want to do as maintainers. This is a volunteer project, after all (and even in a non-volunteer project, tasks would be prioritized and some wouldn't get done because they just weren't high enough priority). What I think many people are saying in this thread is that, among all the things that a Debian package maintainer could do to improve the package and user experience of those using the package, being a go-between for Debian bug reporters and upstream is something they consider low priority. It may be something they'd be willing to do if they have free time after doing other work, or it may be so low-priority that it's below the threshold of work they're willing to volunteer for, but either way it's just less important than other things that need doing and therefore will often go undone. That seems like a reasonable position to take to me. I think the question of to what extent a person is accomplishing a maintainer role is really only a useful question to ask project-wide, in places like debian-devel (as opposed to personally, when deciding what one wants to take on) if we're considering either replacing the maintainer or booting the package for not being properly maintained. I have a hard time imagining not forwarding bugs upstream to rise to the level of undone tasks to warrant contemplating either of those actions in most cases. Note that most of the push-back against the work of forwarding bugs upstream is from maintainers of huge packages like X, GNOME, or the kernel, teams that have been begging for help for years. We're obviously not going to kick those packages out of the archive, and we're obviously not going to replace the existing maintainers given that the problem we're having is no one volunteering to be a maintainer (and hence no one else is going to do a better job than the people who are already working on those packages). So there doesn't seem to be much point in discussing things from that angle. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/874o9du24c@windlord.stanford.edu
Re: Forwarding bugs upstream
Russ Allbery r...@debian.org writes: What I think many people are saying in this thread is that, among all the things that a Debian package maintainer could do to improve the package and user experience of those using the package, being a go-between for Debian bug reporters and upstream is something they consider low priority. It may be something they'd be willing to do if they have free time after doing other work, or it may be so low-priority that it's below the threshold of work they're willing to volunteer for, but either way it's just less important than other things that need doing and therefore will often go undone. That seems like a reasonable position to take to me. And to me. None of that argues against the maintainer role entailing that work, though. So there doesn't seem to be much point in discussing things from that angle. Right. My point with raising it was merely to show that it goes both ways: there's not much point saying “you have to do the work”, just as there's not much point saying “nobody can force me to do anything”. Either of those simply polarises the discussion, which is not helpful. Rather, I'm arguing that the maintainer role, as a mediator and interface between upstream and the Debian user, entails a whole lot of different tasks, and being a mediator in the discussion between upstream-who-doesn't-care-about-Debian-specifically and Debian-user-with-a-bug-report is part of that role. To argue that is *not* to require or demand that anyone do any work, nor to strip anyone of their role. I wish I knew how to avert the seemingly inevitable charges of that which arise any time we discuss what the maintainer role entails. -- \ “When I was a kid I used to pray every night for a new bicycle. | `\Then I realised that the Lord doesn't work that way so I stole | _o__) one and asked Him to forgive me.” —Emo Philips | Ben Finney -- 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/878vypd66r@benfinney.id.au
Re: Forwarding bugs upstream
On Wed, 12 Jan 2011 16:56:56 +, Ian Jackson wrote: I think it is always reasonable for the maintainer to forward the bug upstream. But what I think is bad is _demanding_ or _requiring_ the maintainer to forward the bug upstream. If they don't want to do that for whatever reason then asking the submitter to do so is IMO perfectly acceptable. We can't demand or require anyone to do anything. Yet we expect maintainers to answer bug reports, provide packages, etc. The fact that you can't force anyone to do anything doesn't mean you can't say that some behavior is preferred or considered best practice. -- Saludos, Felipe Sateler -- 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/iglhb6$8n...@dough.gmane.org
Re: Forwarding bugs upstream
Olaf van der Spek writes (Re: Forwarding bugs upstream): On Thu, Jan 13, 2011 at 12:12 AM, Sune Vuorela nos...@vuorela.dk wrote: Will this mean that the problem will somehow disappear from Debian? Because if it's a problem detected within Debian it's my feeling that it will have to be tracked within Debian till the problem is in Debian no more. No. but it is a way to be honest about teh issue: We are not spending debian time on fixing it. That's better than no response to a bug report at all. That's true too. But on the whole I think it would be better to leave these kind of work-needed upstream bugs open in the Debian BTS but tagged and filed appropriately. As I understand it we are not in danger of having infrastructure capacity problems at the BTS due to these bugs, and the maintainers who think they are a very low priority don't want to see them can easily arrange that with the pretty sophisticated filtering and searching we have nowadays. But I think that's a matter of best practice and not something I'd beat a maintainer up about. I do want to say that from the opposite angle, I do often really appreciate it when a maintainer has the time to engage with upstream over my bugs. I often file bugs in the Debian BTS which are really upstream bugs because I think this is going to produce a better overall result for less effort - eg, because Debian and the Debian maintainer are better organised than the upstream. Many maintainers seem to appreciate this too. But if a maintainer tells me please go and talk to them yourself or even please stop filing these kind of upstream bugs in Debian - you know how to do it yourself upstream and I have enough to do already then that's a wish I would respect. So I guess ultimately what I'm saying is that questions like this can't really be one-size-fits-all. And it is the maintainer who is the right person to decide what the best approach is. Ian. -- 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/19758.18548.460171.590...@chiark.greenend.org.uk
Re: Forwarding bugs upstream
Felipe Sateler writes (Re: Forwarding bugs upstream): On Wed, 12 Jan 2011 16:56:56 +, Ian Jackson wrote: I think it is always reasonable for the maintainer to forward the bug upstream. But what I think is bad is _demanding_ or _requiring_ the maintainer to forward the bug upstream. If they don't want to do that for whatever reason then asking the submitter to do so is IMO perfectly acceptable. We can't demand or require anyone to do anything. Yet we expect maintainers to answer bug reports, provide packages, etc. The fact that you can't force anyone to do anything doesn't mean you can't say that some behavior is preferred or considered best practice. Yes. But in this case I don't think we should be expecting maintainers to necessarily shepherd bug reports upstream. I don't think a maintainer who fails to do so is failing in their job as maintainer. The maintainer should decide whether they think doing that is a useful thing to be doing for that package or that bug, and communicate this decision to the user (and set the bug state accordingly). Ian. -- 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/19758.18829.337578.183...@chiark.greenend.org.uk
Re: Forwarding bugs upstream
On Thu, Jan 13, 2011 at 1:38 AM, Ian Jackson ijack...@chiark.greenend.org.uk wrote: But in this case I don't think we should be expecting maintainers to necessarily shepherd bug reports upstream. I don't think a maintainer who fails to do so is failing in their job as maintainer. The maintainer should decide whether they think doing that is a useful thing to be doing for that package or that bug, and communicate this decision to the user (and set the bug state accordingly). Maybe some tools (PTS) should warn about bugs that are older than X days and are still unclassified? Olaf -- 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/aanlkti=vahvnar2du9u7r8udza8jcmmh76u0+6wnd...@mail.gmail.com
Re: Forwarding bugs upstream
Ian Jackson ijack...@chiark.greenend.org.uk writes: As I understand it we are not in danger of having infrastructure capacity problems at the BTS due to these bugs, and the maintainers who think they are a very low priority don't want to see them can easily arrange that with the pretty sophisticated filtering and searching we have nowadays. Yes. If nothing in Debian will happen to a bug report until upstream gets their act together, tagging to indicate that is fine. Closing the bug isn't appropriate, since the bug as reported still exists in Debian. But I think that's a matter of best practice and not something I'd beat a maintainer up about. Same here. I do want to say that from the opposite angle, I do often really appreciate it when a maintainer has the time to engage with upstream over my bugs. Perhaps we don't say this enough in public. But if a maintainer tells me please go and talk to them yourself or even please stop filing these kind of upstream bugs in Debian - you know how to do it yourself upstream and I have enough to do already then that's a wish I would respect. As would I; but, as stated earlier, often the only way I can feasibly respect such a wish is not to report such bugs at all. So I guess ultimately what I'm saying is that questions like this can't really be one-size-fits-all. And it is the maintainer who is the right person to decide what the best approach is. Sure, but that's true of just about anything associated with the maintainer role. It's still good to discuss and argue the various positions for what the maintainer role should entail. -- \ “Dad always thought laughter was the best medicine, which I | `\guess is why several of us died of tuberculosis.” —Jack Handey | _o__) | Ben Finney -- 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/87y66pbnua@benfinney.id.au
Re: Forwarding bugs upstream
Olaf van der Spek writes (Re: Forwarding bugs upstream): Maybe some tools (PTS) should warn about bugs that are older than X days and are still unclassified? That's just a way to make more noise. They show up in the BTS searches already. Ian. -- 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/19758.21196.655652.587...@chiark.greenend.org.uk
Re: Forwarding bugs upstream
On Tue, 2011-01-11 at 23:54 +, brian m. carlson wrote: I've noticed a trend lately that I am often asked to forward the bugs I report to the Debian BTS upstream, either by the maintainers or automatically by a bug script. I believe, and I continue to believe, that maintainers should forward bugs upstream instead of requiring (or strongly encouraging) users to do so. If a bug is not readily reproducible or isolatable, it may be necessary to pass it over to an upstream maintainer who will know what further questions to ask. But they need to send those questions to the user, not to the Debian maintainer. In the kernel team, we often ask users to report bugs upstream for that reason. I understand that maintainers' time is limited and that forwarding bugs is not an enjoyable task. But I also understand that having a BTS account for the upstream BTS of each of the 2405 packages I have installed on my laptop (not to mention my other machines) is simply not practical. Surely you don't find bugs in all of those packages? I also don't have the benefit of the rapport that a maintainer has with upstream and knowledge of upstream practices. I try very hard to make my bug reports simple, clear, and well-defined (often with testcases) to make it easier for them to be forwarded and fixed, [...] In that sort of case, yes, it is hard to see a justification for a maintainer requiring you to report again upstream. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Re: Forwarding bugs upstream
Ben Hutchings b...@decadent.org.uk (12/01/2011): If a bug is not readily reproducible or isolatable, it may be necessary to pass it over to an upstream maintainer who will know what further questions to ask. But they need to send those questions to the user, not to the Debian maintainer. In the kernel team, we often ask users to report bugs upstream for that reason. Ditto on the X side. Having a low-power proxy between developers and users is quite a bad idea (induces delays and higher load). KiBi. signature.asc Description: Digital signature
Re: Forwarding bugs upstream
brian m. carlson sand...@crustytoothpaste.net writes: I've noticed a trend lately that I am often asked to forward the bugs I report to the Debian BTS upstream, either by the maintainers or automatically by a bug script. I believe, and I continue to believe, that maintainers should forward bugs upstream instead of requiring (or strongly encouraging) users to do so. +1 I understand that maintainers' time is limited and that forwarding bugs is not an enjoyable task. But I also understand that having a BTS account for the upstream BTS of each of the 2405 packages I have installed on my laptop (not to mention my other machines) is simply not practical. I also don't have the benefit of the rapport that a maintainer has with upstream and knowledge of upstream practices. Yes, I agree with that position. It is even more reasonable when one considers that the person who has chosen to be a maintainer for Debian package ‘foo’ has some amount of obligation to have an account with the upstream BTS for ‘foo’, whereas an arbitrary user of ‘foo’ does not. I try very hard to make my bug reports simple, clear, and well-defined (often with testcases) to make it easier for them to be forwarded and fixed, and if they're not, I'm happy to clarify or test so that they can be. And I try to submit patches as my time and abilities permit. If it happens that I need to be added to the CC list of the upstream bug report to assist in fixing it, I'm usually fine with that if asked. Yes, this is all a fair expectation of the user by the maintainer, in exchange for being the contact point for the package in Debian. -- \ “To stay young requires unceasing cultivation of the ability to | `\ unlearn old falsehoods.” —Robert Anson Heinlein | _o__) | Ben Finney pgpKH2bcp3YnB.pgp Description: PGP signature
Re: Forwarding bugs upstream
Quoth Cyril Brulebois k...@debian.org, on 2011-01-12 01:59:03 +0100: If a bug is not readily reproducible or isolatable, it may be necessary to pass it over to an upstream maintainer who will know what further questions to ask. But they need to send those questions to the user, not to the Debian maintainer. In the kernel team, we often ask users to report bugs upstream for that reason. Ditto on the X side. Having a low-power proxy between developers and users is quite a bad idea (induces delays and higher load). I tend to think what would be ideal in such cases is for the package maintainer to go through the overhead motions of forwarding that require a heavy context switch (i.e., setting the ball rolling) and then subscribe the user to the relevant bug by email or some other similar communication mechanism. Which upstream bug trackers, if any, would make the above not work? Here I'm ignoring things like maintainer time to do the forwarding, assuming that that can be analyzed separately. Mainly I'm wondering about cases where the user essentially _can't_ communicate about the bug directly without going through rigamarole to create an account first or thereabouts; is this common? If so, and assuming it's much more expensive for the user to switch into bug reporting context, I find it likely that many users would give up at that point rather than having to report the bug a second time after having already expended the context switch effort to report it once. --- Drake Wilson -- 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/20110112012933.ga3...@drache.begriffli.ch
Re: Forwarding bugs upstream
On Tue, 2011-01-11 at 18:29 -0700, Drake Wilson wrote: Quoth Cyril Brulebois k...@debian.org, on 2011-01-12 01:59:03 +0100: If a bug is not readily reproducible or isolatable, it may be necessary to pass it over to an upstream maintainer who will know what further questions to ask. But they need to send those questions to the user, not to the Debian maintainer. In the kernel team, we often ask users to report bugs upstream for that reason. Ditto on the X side. Having a low-power proxy between developers and users is quite a bad idea (induces delays and higher load). I tend to think what would be ideal in such cases is for the package maintainer to go through the overhead motions of forwarding that require a heavy context switch (i.e., setting the ball rolling) and then subscribe the user to the relevant bug by email or some other similar communication mechanism. Which upstream bug trackers, if any, would make the above not work? [...] Bugzilla requires that each subscribed email address has an account. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Re: Forwarding bugs upstream
On Wed, Jan 12, 2011 at 9:29 AM, Drake Wilson dr...@begriffli.ch wrote: Which upstream bug trackers, if any, would make the above not work? Sourceforge and probably Gforge/FusionForge trackers. The only tracker I'm aware of which would work is Trac, some instances of which allow anyone to put in anyone else's email address as the author of the bug. -- bye, pabs http://wiki.debian.org/PaulWise -- 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/aanlktinlhylwoagoer0znglsld5xb5qeumh3vmdet...@mail.gmail.com
Re: Forwarding bugs upstream
(Woopsy, forgot to send to the list the first time.) Quoth Paul Wise p...@debian.org, on 2011-01-12 10:55:34 +0800: [among other responses] Sourceforge and probably Gforge/FusionForge trackers. The only tracker I'm aware of which would work is Trac, some instances of which allow anyone to put in anyone else's email address as the author of the bug. So basically most or all of them, then. Right. This doesn't leave much in the way of good options: - Having the user report bugs twice, with the second one being after a delay, creates choppy context switches that can require a pile of extra mental energy (at least in my estimation; I wouldn't mind being shown to be wrong). The create an account process is especially choppy because it requires multiple internal context switches to handle email verification and so forth. This results in giving up. At the least, as a data point, when I've reported bugs for which I didn't intend to be strongly active in helping develop a fix, it's taken more than double the total energy output when I've had to forward the bug myself: the choppy switching overwhelms everything else, and much of the time I never get around to doing it at all, whereas replying to another email would have happened quickly. - Having the maintainer be the reporter of record for upstream can result in forwarding hassle per unit time for the maintainer which is O(N) in the number of bugs. It shifts the annoyance from the previous option onto the maintainer, and condenses it in the process (the maintainer doesn't have to establish an association with the tracker multiple times, c.) but the condensation is only large for high loads for the forwarding part, and there's lots of communication delays. It also means the maintainer has to spend continuous work on things that are not necessarily useful to the package directly. - Having the maintainer forward the bug report but make the user the reporter of record doesn't work because they don't have the authority to do that, nor to override the hassle of initial association between the user and the upstream bugtracker. I wonder whether there's an optimization possible here, at least: perhaps the maintainer could forward first, but then _if_ at least N messages need to be forwarded between upstream and user, request that the user take control of the upstream bug to streamline the rest of the flow. N could be 1 or 2, for instance. --- Drake Wilson -- 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/20110112031934.ga6...@drache.begriffli.ch
Re: Forwarding bugs upstream
On 01/11/2011 05:54 PM, brian m. carlson wrote: I've noticed a trend lately that I am often asked to forward the bugs I report to the Debian BTS upstream, either by the maintainers or automatically by a bug script. I believe, and I continue to believe, that maintainers should forward bugs upstream instead of requiring (or strongly encouraging) users to do so. Hi Brian, I'm going to have a slightly different viewpoint on this. I think it is perfectly fine for a user to submit a bug report to the Debian BTS first. They may not always be equipped to know what is a Debian and what is an upstream bug. And I also think it ought to be perfectly valid for the Debian developer to close the bug saying it's an upstream issue, together with a pointer to the upstream BTS and promise to get involved should there be any question about the Debian packaging, environment, etc. Now, here's how it proceeds if I have to forward a bug upstream for Bacula, which uses Mantis. Creating a Mantis account takes 30 seconds, but Mantis won't email reports to people without accounts, and the only way to add stuff to it is on the web. So, here's how it goes: 1) User submits bug report to Debian. 2) I decide if it is clearly an upstream issue. 3) I go to Mantis and fill out the fields by copying data from the user's bug report. 4) I mark the bug forwarded and email the user that it's happened. 5) Upstream inevitably has questions or other things for user to try. 6) I forward that email to Debian BTS and user. Maybe I download an attachment from the Mantis report and attach it to the email. 7) User replies, possibly while I'm sleeping. I log in to Mantis and copy and paste the answer. I also save off attachments from the email and then go and attach them to the Mantis report. 8) This continues. I'm adding zero value here. Zero. It is a huge and frustrating waste of my time. It is also frustrating for upstream, who would rather just talk with the user directly and involve me if they think there's a Debian-specific question. I don't understand why some users want it to go this way, but many clearly do despite the fact that they get worse service. I'm going to be brutally honest and admit here that being a copy and paste monkey between emails and web forms is something I really dislike doing. It is something that makes Debian the opposite of enjoyable, and I think I let those tasks sit longer than I should, and work on things instead where I can actually contribute (such as fixing Debian bugs). I have a sense that I'm not alone. I've noticed that there are certain major packages for which upstream bugs tend to get ignored for a year, then get a big sweep asking if they're still issues, then get ignored for a year again. I won't mention names here, but I don't think it's necessarily entirely blame to be laid at maintainers' feet. I just go and submit upstream bugs upstream on those and go on my merry way. Maintainers in Debian do undertake certain responsibilities. But I think that being copy and paste monkeys shouldn't be one of them. If I were getting paid to work a helpdesk, sure. But really, I think it is nonsensical for an end user to expect me to do this because the user doesn't want to spend 30 seconds creating an account on an upstream BTS. That's not what Free Software is all about. And it has Debian maintainers wasting time. I think that promising that Debian maintainers will always shepherd bugs upstream is promising something we don't actually deliver on very well, and probably never have. Perhaps we should stop promising it. This is not to criticize Brian here; he has been perfectly courteous and up-front in his presentation. -- John -- 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/4d2d1cdd.2010...@complete.org
Re: Forwarding bugs upstream
John Goerzen jgoer...@complete.org writes: Now, here's how it proceeds if I have to forward a bug upstream for Bacula, which uses Mantis. Creating a Mantis account takes 30 seconds I don't know Brian's position on this, but “time to create an account with arbitrary upstream BTS” isn't the issue. “Having an account on a new service which in all likelihood will be unused by me after very few messages” is the main concern; growing numbers of unused site accounts are either a management hassle, or a foolish security hole, or both. but Mantis won't email reports to people without accounts, and the only way to add stuff to it is on the web. That sucks. It seems like a problem that is best addressed upstream, by using a better BTS that can communicate via email. I don't necessarily think that advocating for a better BTS needs to be solely the job of the Debian package maintainer though; I'm merely identifying explicitly where I see the cause of the hassle in that case. I'm adding zero value here. Zero. It is a huge and frustrating waste of my time. Not in my view. I appreciate the Debian package maintainer acting in the interest of “lower the barrier for each Debian user of this package to report useful bug information”. To be clear: Thank you for the time you spend doing this, and the same to any other Debian maintainer who does unromantic work to keep the good information flowing. It is also frustrating for upstream, who would rather just talk with the user directly and involve me if they think there's a Debian-specific question. Hopefully that motivation can, in some cases if not all, be used to help the upstream see that their chosen BTS is an impediment (as described above). I don't understand why some users want it to go this way, but many clearly do despite the fact that they get worse service. Quite the opposite, from my position. A great feature of the Debian BTS is that any user can interact with it through a standard interface without maintaining multiple separate identities; heck, without having to create a single new identity at all. Having to create and maintain (or fail to maintain) identities with balkanised upstream BTSen is bad enough as a package maintainer. As a mere user of all the other packages on my computers, I consider it too high a barrier. I'm going to be brutally honest and admit here that being a copy and paste monkey between emails and web forms is something I really dislike doing. It is something that makes Debian the opposite of enjoyable, and I think I let those tasks sit longer than I should, and work on things instead where I can actually contribute (such as fixing Debian bugs). I can appreciate that, and I feel the same way when I'm in that position as a maintainer. You're certainly not alone. I think that promising that Debian maintainers will always shepherd bugs upstream is promising something we don't actually deliver on very well, and probably never have. Perhaps we should stop promising it. I think the situation is certainly sub-optimal. But surely the solution is not to expect Debian users to take on the work; that seems worse in every way. At the least, the increased barrier that would result can't help but dramatically reduce the number of upstream bug reports that get useful information from Debian users. Rather, we should be using the discomfort of all parties described to press actively for a better solution to the problem for everyone. It's not a problem that can reasonably be expected to be solved once and for all, at least not while upstream developers are free to pick arbitrary bad BTS software. But that doesn't mean efforts to improve the situation at its source are futile. -- \ “If we have to give up either religion or education, we should | `\ give up education.” —William Jennings Bryan, 1923-01 | _o__) | Ben Finney -- 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/87oc7md8at@benfinney.id.au
Re: Forwarding bugs upstream
On 12 January 2011 14:15, John Goerzen jgoer...@complete.org wrote: 8) This continues. For what it is worth, I generally will ask the submitter to use the upstream bug tracking system if there is any dispute or problems with the bug report. Sure, this isn't ideal, but seems to me to be a compromise between getting the user to file the report upstream and having the Debian maintainer act as the relay for all messages. -- Brian May br...@microcomaustralia.com.au -- 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/aanlktinyabb5jggz6whajvndta62cc8maefpnueiy...@mail.gmail.com
Re: Forwarding bugs upstream
I understand that maintainers' time is limited and that forwarding bugs is not an enjoyable task. But I also understand that having a BTS account for the upstream BTS of each of the 2405 packages I have installed on my laptop (not to mention my other machines) is simply not practical. I also don't have the benefit of the rapport that a maintainer has with upstream and knowledge of upstream practices. Upstream tend to request users to install latest and greatest versions, often for source or using other unsafe methods. Not only for package in question but also for explicit and implicit dependences. Non-technical follow these broken advices and break their systems. And then complain that Debian is problematic for them. I think that forwarding user upstream is acceptable only for deeply technical users. But but not as a default policy. -- 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/201101120952.53...@zigzag.lvk.cs.msu.su
