Re: bug reporting workflow is outdated
schrieb Ian Jackson am 2011-05-24 13:34:
> Patrick Strasser writes ("Re: bug reporting workflow is outdated"):
>> What is the advantage of having a mail-only BTS reporting mechanism?
>
> The advantage is that no-one can make _other_ user interfaces to bug
> submission that we don't want. (Or at least, they are deterred from
> doing so.)
Is it about control?
What prevents someone to make an additional tool to report bugs?
In the scope of packages this could for sure managed by some agreement
which tools are supported and recommend or even accepted in Debian.
In a global scope, one can now make a web tool that generates mails to
reportbug.d.o., you can do nothing about it. You could ad some mechanism
to limit bug submissions from such tools on the Debian side.
In the end the situation with some additional transport would not change
at all in this respect.
> I agree that using http as a transport for reportbug would be fine, in
> itself. But if you read this thread you can see numerous suggestions
> that "if we had an http interface we could also do X Y Z".
Of course that suggestions would be made, and a lot of them would be not
so bad. What's the problem with good ideas?
> Apparently, if we don't want X Y Z done then we must resist an http
> interface for bug submission
I do not see that argument. There is no rule that says that implementing
a requested feature implies a obligation to implement every other
requested feature.
> even if it makes it hard for reportbug to
> work correctly, because it's the thin end of a wedge.
I try hard to read that not as
"We can't make reportbug more usefull, because that means we would end
in implementing a lot of clever things. Lets stay with an limited system
to save the trouble."
One of the greatest features of Debian is its openness for user
contribution. Reportbug should not present a intentional barrier in user
contribution.
> The fat end is a web form for users to submit bugs.
Would that be so bad?
Pros and cons for reportbug HTTP transport:
- You would not get all the meta-info you get with reportbug, like
installed package versions. That is only the case for third-party
reporting tools, not reportbug HTTP transport.
+ You would not rely on email transport alone.
+ Symmetry to the bug database web frontend.
+ HTTP transport is connection orientated, the reporter gets immediately
feedback about his/her submission.
+ No rather complex MTA setup necessary, only proxy setup possibly needed.
Regards
Patrick
--
Engineers motto: cheap, good, fast: choose any two
Patrick Strasser <patrick dot strasser at student dot tugraz dot at>
Student of Telemati_cs_, Techn. University Graz, Austria
Reply to: