Re: Bug Tracking

[John W. Eaton]

On 30-Mar-2010, Rik wrote:

| > From:
| > Rob Mahurin <address@hidden>
| > Date:
| > Fri, 26 Mar 2010 14:49:39 -0400
| > To:
| > "John W. Eaton" <address@hidden>
| > 
| > To:
| > "John W. Eaton" <address@hidden>
| > CC:
| > Thorsten Meyer <address@hidden>, address@hidden
| > 
| > 
| > On Wed, Mar 24, 2010 at 04:36:19PM -0400, John W. Eaton wrote:
| >> Do you have a suggestion for how we can update it to do something
| >> useful?  Should it simply print out information about how to report
| >> bugs, possibly with information that would be useful to include in the
| >> tracker's submission form?
| > 
| > Having bug_report actually report bugs is a nice feature.  
| > 
| > urlwrite can send POST requests, so in principle, bug_report could
| > collect the desired fields, submit the form, and give the user a URL
| > to examine their bug in the tracker.
| > 
| > This would introduce a maintenance burden to keep bug_report
| > synchronized with the tracker's submission form.  For instance, right
| > now the submission page is asking a captcha (paptcha?) question about
| > George Orwell, and that question will probably be different in two
| > years when slow upgraders are still using the soon-to-be-released Octave.
| > 
| > I have just done this successfully:
| >     https://savannah.gnu.org/bugs/index.php?29354
| > 
| > There's some other auto-generated form fields, which can perhaps be
| > identified by some fancy text-scraping.
| >  
| > Comments?
| Rob,
| 
| I like this.  To be most useful I think it should also include the
| information about the user's environment that bug_report currently
| collects.  Can your urlwrite script also attach this information as a file?

I like the concept, but I'm not sure about implementing it because it
seems fragile to me.  For example, the bug reporting script will break
if the bug tracker on savannah changes, and we don't really have much
control over what changes are made to savannah.  Even if we did,
linking the bug reporting script too closely with the current tracker
means that it is difficult to switch in the future.  So unless someone
has a good way to decouple the reporting script and tracker, I think
the best solution is to just display the information that should be
reported in the tracker and ask the user to submit the report.

jwe