... or at least for some definition of working.
The mails are indeed sent to parrotbug, parrotstatus-ok and
parrotstatus-nok (at parrotcode.org) for resp. bug reports, ok reports
or nok reports. And since I don't think those addresses are set up...
"parrotbug -h" will give you some indications on how to use it, but
basically you can do one of the following 4 actions:
- "parrotbug -ok" => report a successful build
- "parrotbug -nok" => report a failed build
- "parrotbug -d" => dump your config and environment
- "parrotbug" => prompts for questions and send
TODO:
- clean up / factorise code in send_msg
- allow for user to review what will be sent
- tests with various flavours of perl (and especially perl 5.005)
- tests with various OS
- change the flags set (and maybe use Getopt::Long)
Leopold Toetsch wrote:
> Jerome Quelin <[EMAIL PROTECTED]> wrote:
> > - 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.
perlbug do send config information on ok reports...
> > - should we include more than myconfig in nok / bug reports?
> OS-Version, compiler-version. $PConfig{} is lacking some info here.
The reports include os name, os version, arch name and cc version.
*But* those information are all taken from Perl's Config module...
> 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"
Yup, but what to do? It's not the goal of parrotbug to automatically run
"make <insert-here-your-favorite-test-target>"...
> And an ok report is ok, if "make testC" fails on windows/msc, but is
> really nok, if it fails on gcc based systems.
Erm. I'm not this far in the work :-)
Jerome
--
[EMAIL PROTECTED]
