Re: Bug Tracking

I've removed p5p from the distribution list, as I suspect that most of the
interested parties are already a member of the bugmongers list.

> > *) How long until we could have a perl6 database up and functioning?  I
> > think it would be wise to capture feature requests in there.
> It's a bug database, not a feature request database, they should go to:
> [email protected]
> shouldn't they ?-)

Traditionally, bug tracking and feature tracking are similar enough to
warrant sharing a database.  Perl may be unique enough for that not to
apply.  In fact, with the new RFC approach, it probably is a moot point
except to maybe make the librarian's job easier.

> Humm, perl6... I'd like to get a bit more definitive on what is exactly
> required before committing myself to any time deadlines.  Where is this
being
> discussed precisely?

perl-qa is probably the best forum for this at the moment.

> Does this require a completely seperate database, or one which has a
product
> flag(perl5, perl6, donaldduck, etc.) to seperate out functionality,
access,
> search results, etc?
> I mean, will people want to have to go to a seperate web interface, for
all
> perl6 bugs, or a seperate email interface etc.?  It could be for example
that
> a bug is fixed by a particular patch, and this patch has 3 tests
associated
> with it.  These tests may want to go against both databases, or a
> single/both/all product/s.  Will it be easier to have it all in one place,
or
> split?
> Searching for old/new bugs related to the define flags for example may be
> better all in one db?
> etc?

A product field is probably the cleanest option, but a new database would be
acceptable to me.

> > *) Will it forward email based on the category of the bug (core,
standard
> > modules, etc.)?
> I suppose it could, though it's currently setup to mail-forward based on
the
> os-relevant address, and that could be extended fairly easily.
>
> So, if you send (from the new spec) to:
>  Module:         [email protected] -> ([email protected])
>  Generic:        [email protected] or [email protected] ->
> ([email protected])
>  Unix:           [email protected] or [email protected] ->
> ([email protected])
>  Win32:          [email protected] ->
> ([email protected])
>  Macos:          [email protected] -> ([email protected])
>  Test:           [email protected] -> ([email protected])
>
> Now we have this neat namespace, would that not be able to cover it too,
like
> this:
> [email protected]
> etc?  Note that this particular line is not currently implemented, but
would
> not be hard to do, if deemed useful.

That is pretty much the functionality I was hoping for.  Is it easy to add
new rules?

>
> Or should we get *@bugs6.perl.org running, perhaps?

Hmm... implementation details are up to you, of course.

> > *) Do you think it needs any updates for the Perl6 development format,
and,
> Undoubtedly, knowing what exactly is required, would be good though.

I don't think anyone knows exactly what's required yet.

 Of course.  The code is downloadable for you to read, modify and send in
> patches, or to email in suggestions against, etc.

Will do.

> Hmmmm, sounds like we need a test table:
> n tests <-> n tickets
> ?

Good point.  It certainly could eventually be a many-to-many relationship.
However, I think when a bug is reported, one test field would probably be
sufficient.  The other tests would most likely be added later, as someone
tries to narrow down the problem.  It would be nice to be able to automate
application of the tests, but that would require bug submitters to adhere to
a testing framework, which may be difficult to have happen.

One nice thing with this suggestion is that we could actually use the bug
database as the test repository.  And maybe could extend some of the bug
concepts to tests as well.  For example, the ability to mark tests as
duplicates would help keep the testbed down to a reasonable subset.

++t