> > I'd rather something that can actually live on bugs.perl.org.
> How about a bugs.perl.org Kwiki?
I have not yet drunk that particular Kool Aid.
I'm happy to accept patches. I also want to retain some level of
editorial control over it, to make sure we don't make right-turns.
-R
chromatic wrote in perl.qa :
> One idea is attaching a simple test case to every bug report that
> doesn't have test code that's nearly right for the core. It's a lot
> easier to touch up a test case than it is to write one, so we could do
> a lot of good by turning bug reports into executable
On Friday, July 18, 2003, at 10:36 AM, Tony Bowden wrote:
What's the current approach to turning perlbugs into tests?
In general, the person who fixes the bug writes a regression test for
the bug. The pumpkings and other porters are really good about making
sure patches have tests.
Should they
At Fri, 18 Jul 2003 18:19:19 +0100,
Tony Bowden wrote:
> I've been chatting with Casey about how we should best be dealing with
> the perlbug RT interface - e.g. what to do when you come across a bug
> that's resolved, what the various statuses mean etc.
The proper place for this particular discus
What's the current approach to turning perlbugs into tests?
Should they be done as TODOs? Is there a distinct set of test files for
them? etc? Can they use Test::More? etc. etc. etc.
e.g. http://bugs6.perl.org/rt2/Ticket/Display.html?id=5430
can have a fairly simple test like:
package
I've been chatting with Casey about how we should best be dealing with
the perlbug RT interface - e.g. what to do when you come across a bug
that's resolved, what the various statuses mean etc.
There doesn't seem to be any documentation anywhere on this, and we
thought the QA wiki might be a usef
