Forwarding bugs upstream

classic Classic list List threaded Threaded
170 messages Options
1234 ... 9
Reply | Threaded
Open this post in threaded view
|

Forwarding bugs upstream

brian m. carlson-2
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.

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.

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.

To clarify, this is not in reference to any particular package or
maintainer; it's just something I've noticed and wanted to bring up.

--
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 (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Forwarding bugs upstream

Ben Hutchings-3
On Tue, 2011-01-11 at 23:54 +0000, 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 (845 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Forwarding bugs upstream

Cyril Brulebois-4
Ben Hutchings <[hidden email]> (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 (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Forwarding bugs upstream

Ben Finney-5
In reply to this post by brian m. carlson-2
"brian m. carlson" <[hidden email]> 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

attachment0 (851 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Forwarding bugs upstream

Drake Wilson-3
In reply to this post by Cyril Brulebois-4
Quoth Cyril Brulebois <[hidden email]>, 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 [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20110112012933.GA3334@...

Reply | Threaded
Open this post in threaded view
|

Re: Forwarding bugs upstream

Ben Hutchings-3
On Tue, 2011-01-11 at 18:29 -0700, Drake Wilson wrote:

> Quoth Cyril Brulebois <[hidden email]>, 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 (845 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Forwarding bugs upstream

Paul Wise via nm
In reply to this post by Drake Wilson-3
On Wed, Jan 12, 2011 at 9:29 AM, Drake Wilson <[hidden email]> 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 [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/AANLkTinLHyLwOAGoer0ZNgLsLd5xb5qEUmH3VMDetbdE@...

Reply | Threaded
Open this post in threaded view
|

Re: Forwarding bugs upstream

John Goerzen-3
In reply to this post by brian m. carlson-2
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 [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/4D2D1CDD.2010608@...

Reply | Threaded
Open this post in threaded view
|

Re: Forwarding bugs upstream

Drake Wilson-3
In reply to this post by Paul Wise via nm
(Woopsy, forgot to send to the list the first time.)

Quoth Paul Wise <[hidden email]>, 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 [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20110112031934.GA6771@...

Reply | Threaded
Open this post in threaded view
|

Re: Forwarding bugs upstream

Ben Finney-5
In reply to this post by John Goerzen-3
John Goerzen <[hidden email]> 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 [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/87oc7md8at.fsf@...

Reply | Threaded
Open this post in threaded view
|

Re: Forwarding bugs upstream

Brian May-11
In reply to this post by John Goerzen-3
On 12 January 2011 14:15, John Goerzen <[hidden email]> 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 <[hidden email]>


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/AANLkTinYaBb5jgGZ6wHAjvnDta62cC8maEFpNuEiy-gj@...

Reply | Threaded
Open this post in threaded view
|

Re: Forwarding bugs upstream

Nikita Youshchenko
In reply to this post by brian m. carlson-2
> 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 [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/201101120952.53271@...

Reply | Threaded
Open this post in threaded view
|

Re: Forwarding bugs upstream

Antonin Kral
In reply to this post by Drake Wilson-3
* Drake Wilson <[hidden email]> [2011-01-12 08:09] wrote:

> Quoth Paul Wise <[hidden email]>, 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 [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20110112075111.GA3631@...

Reply | Threaded
Open this post in threaded view
|

Re: Forwarding bugs upstream

Andrei POPESCU-2
In reply to this post by Paul Wise via nm
On Mi, 12 ian 11, 10:55:34, Paul Wise wrote:
> On Wed, Jan 12, 2011 at 9:29 AM, Drake Wilson <[hidden email]> 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 (501 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Forwarding bugs upstream

Josselin Mouette
In reply to this post by brian m. carlson-2
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 [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/1294821223.25195.68.camel@meh

Reply | Threaded
Open this post in threaded view
|

Re: Forwarding bugs upstream

Roland Mas
In reply to this post by Drake Wilson-3
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 [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/8739oywkdx.fsf@...

Reply | Threaded
Open this post in threaded view
|

Re: Forwarding bugs upstream

Sune Vuorela-2
In reply to this post by brian m. carlson-2
On 2011-01-11, brian m. carlson <[hidden email]> 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 [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/slrniirb1r.rvp.nospam@...

Reply | Threaded
Open this post in threaded view
|

Re: Forwarding bugs upstream

brian m. carlson-2
In reply to this post by John Goerzen-3
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 (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Forwarding bugs upstream

Gunnar Wolf
In reply to this post by Ben Finney-5
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 [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20110112153516.GA26836@...

Reply | Threaded
Open this post in threaded view
|

Re: Forwarding bugs upstream

Ian Jackson-2
In reply to this post by John Goerzen-3
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 [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/19757.56337.388114.637603@...

1234 ... 9