(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
