Re: Work on the Bug Reporting System (00/08/04)
| From: | Zak Greant | Date: | Sat, 05 Aug 2000 19:07:34 +0000 |
| Subject: | Re: Work on the Bug Reporting System (00/08/04) | ||
| References: | 1 | Groups: | php.qa |
| Request: | Send a blank email to php-qa+get-518@lists.php.net to get a copy of this message | ||
----- Original Message -----
From: "jalal" <the_jalal@yahoo.com>
Sent: Saturday, August 05, 2000 9:59 AM
> >Reported
> > * The process begins when a user submits a bug report
> >
>
> -- the process begins when the user runs some code and something that
> he did not expect happens. This could be because of a real live bug, or
> it could be because the User did not read the docs correctly, or
> something was not documented.
> Maybe we should have some way, in the latter cases, of directly feeding
> the documentation with updates to cover that Users 'bug'.
This could get very tricky. I would prefer that we add some flags to
indicate exactly why bugs were closed. User error in script, undocumented
feature, etc... This would make it simple for an editor to review the bugs
and incorporate them into the manual.
> Feature requests -- are we going to filter out feature requests? Send
> them off to collecting point?
There will be a separate form for feature requests.
Several questions throughout the bug reporting process should catch people
who think that they are reporting a bug, when they are actually asking for a
feature request.
>
> >Regression Test
> > * Once the fix is in place, a regression test should be in place to
catch
> >re-occurences of the bug in the future.
>
> As Stanislav mentioned, many bugs do not fit into a test framework. The
> test framework will mainly work for generic, non-platform dependent
> bugs. (2 semicolons in a row crash the parser... sort of stuff).
> Possibly as time goes on, there will be people who have there own test
> set up and can run their own scripts (PSQL, or Adabas or whatever).
Thanks for the feedback!
Zak