Re: Forwarding bugs upstream

[Drake Wilson <drake@begriffli.ch>]

(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