octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bug Tracking


From: Rik
Subject: Re: Bug Tracking
Date: Tue, 30 Mar 2010 11:52:20 -0700

John W. Eaton wrote:
> 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.

True, the linking does potentially create problems.  The information about
the environment is so helpful during debug that we really do need to find a
way to include it.  Currently if the user starts a bug_report and then
aborts the data is written to a file.

One suggestion is to shorten bug_report.m so all it does is ask for a
filename and write the data to a file.  It then could suggest going to
bugs.octave.org (which is configurable to point to whatever backend we are
using).

--Rik




reply via email to

[Prev in Thread] Current Thread [Next in Thread]