Following Dan's warnocked demand, here's a first version of parrotbug:
- it is very rough
- it currently goes in parrot root dir
- there is no embedded (pod) doc
- it borrows heavily from perlbug
- currently bug reports are sent to bugs-...@bugs6.perl.org
- it only accepts -ok / -nok flags (no *real* bug reports to be edited)
- it includes parrot's myconfig file in the body of the mail
- did I mention that it's still very rough? :-)
I did not checked it in parrot's repository because:
- I don't know where it should go in parrot tree
- the MANIFEST is to be updated too
- the copyright is missing (Dan, please insert correct copyright)
- if it does not go in parrot root dir, then the $parrotdir is to be
updated (should it be updated at Parrot-Configure time? in that case,
how to do it?)
- I'm not sure about the reporting address (Robert, I need your advice
on this one)
I'll continue to work on it when I'll find some time (tomorrow I hope).
But now that there's at least a skeleton, feel free to complete it!
Jerome
--
jqu...@mongueurs.net
This may or may not be good. We need a new processing system (for
perl5 too) to deal with the -ok reports.
> - I'm not sure about the reporting address (Robert, I need your advice
> on this one)
I suppose, it should be something like parrotbug<at>parrotcode.org
Anyone else want to brainstorm bug addresses for parrot?
-R
> I did not checked it in parrot's repository because:
> - I don't know where it should go in parrot tree
tools/dev invoked per "make bugreport"?
> - the copyright is missing (Dan, please insert correct copyright)
All in parrot root is subject to terms in LICENSES.
leo
Copyright notices still should be in the individual files.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Since we need a new system to handle ok/nok/full bug reports, how
'bout we add in:
parrotstatus-ok
parrotstatus-nok
parrotbug
all @parrotcode.org. The first for automated OK reports, the second
for automated nok reports, and the third for actual bug reports.
Yup, that's an idea. But what should we do of the reports? Send them to
p6i, open RT tickets, other?
Then the question arises:
- should we include myconfig in ok reports?
- should we include more than myconfig in nok / bug reports?
Jerome
> Then the question arises:
> - should we include myconfig in ok reports?
No IMHO. But *if* possible, enough information to keep PLATFORMS (or a
better variant of that) up to date - which still needs a bit more inside
tests but I think that we should go towards such a system.
> - should we include more than myconfig in nok / bug reports?
OS-Version, compiler-version. $PConfig{} is lacking some info here.
There are still a lot of issues:
- make test runs now the slow core only
- make fulltest tries to run all cores, but might fail if e.g. JIT or
CGoto isn't avaiable, and we get several results
- EXEC core is untested except for "make testexec"
And an ok report is ok, if "make testC" fails on windows/msc, but is
really nok, if it fails on gcc based systems.
Brrr...
> Jerome
leo