Tony Payne wrote:
>
> > Pros:
> > [Long and detailed list snipped]
>
> Well, now I feel like a jerk for even bringing it up :-).
Nope, that's OK, your turn to get the beer, though?
> Some questions I still have, though:
>
> *) 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 ?-)
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?
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?
> *) 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.
Or should we get *@bugs6.perl.org running, perhaps?
> *) Do you think it needs any updates for the Perl6 development format, and,
Undoubtedly, knowing what exactly is required, would be good though.
> if so, would you like any help from us to make them?
Of course. The code is downloadable for you to read, modify and send in
patches, or to email in suggestions against, etc.
> *) What do you think about a new field in the bug report to hold a test?
> This would make the bugmongers jobs easier in some cases, as there would
> already be a failing test-case at hand. It could even be automated such
> that if the test succeeds against bleedperl, the bug is immediately proposed
> for closure as notabug.
Hmmmm, sounds like we need a test table:
n tests <-> n tickets
?
Ciao
Richard Foley
---
[EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED]
'Ciao' - shorter than 'Aufwiedersehen'
