FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Launchpad User

 
 
LinkBack Thread Tools
 
Old 01-12-2011, 02:19 AM
Drake Wilson
 
Default Forwarding bugs upstream

(Woopsy, forgot to send to the list the first time.)

Quoth Paul Wise <pabs@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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110112031934.GA6771@drache.begriffli.ch">http://lists.debian.org/20110112031934.GA6771@drache.begriffli.ch
 
Old 01-12-2011, 04:01 AM
Ben Finney
 
Default Forwarding bugs upstream

John Goerzen <jgoerzen@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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87oc7md8at.fsf@benfinney.id.au">http://lists.debian.org/87oc7md8at.fsf@benfinney.id.au
 
Old 01-12-2011, 04:30 AM
Brian May
 
Default Forwarding bugs upstream

On 12 January 2011 14:15, John Goerzen <jgoerzen@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 <brian@microcomaustralia.com.au>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: AANLkTinYaBb5jgGZ6wHAjvnDta62cC8maEFpNuEiy-gj@mail.gmail.com">http://lists.debian.org/AANLkTinYaBb5jgGZ6wHAjvnDta62cC8maEFpNuEiy-gj@mail.gmail.com
 
Old 01-12-2011, 05:52 AM
"Nikita V. Youshchenko"
 
Default 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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201101120952.53271@zigzag.lvk.cs.msu.su">http://lists.debian.org/201101120952.53271@zigzag.lvk.cs.msu.su
 
Old 01-12-2011, 06:51 AM
Antonin Kral
 
Default Forwarding bugs upstream

* Drake Wilson <drake@begriffli.ch> [2011-01-12 08:09] wrote:
> Quoth Paul Wise <pabs@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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110112075111.GA3631@bobek.cz">http://lists.debian.org/20110112075111.GA3631@bobek.cz
 
Old 01-12-2011, 07:26 AM
Andrei Popescu
 
Default 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 <drake@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
 
Old 01-12-2011, 07:33 AM
Josselin Mouette
 
Default Forwarding bugs upstream

Le mardi 11 janvier 2011 * 23:54 +0000, 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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1294821223.25195.68.camel@meh">http://lists.debian.org/1294821223.25195.68.camel@meh
 
Old 01-12-2011, 08:18 AM
Roland Mas
 
Default 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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 8739oywkdx.fsf@mirexpress.internal.placard.fr.eu.o rg">http://lists.debian.org/8739oywkdx.fsf@mirexpress.internal.placard.fr.eu.o rg
 
Old 01-12-2011, 12:27 PM
Sune Vuorela
 
Default Forwarding bugs upstream

On 2011-01-11, brian m. carlson <sandals@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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: slrniirb1r.rvp.nospam@sshway.ssh.pusling.com">http ://lists.debian.org/slrniirb1r.rvp.nospam@sshway.ssh.pusling.com
 
Old 01-12-2011, 01:56 PM
"brian m. carlson"
 
Default 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
 

Thread Tools




All times are GMT. The time now is 07:03 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org