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 <jqu...@mongueurs.net> 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
--
jqu...@mongueurs.net
Not yet. I'm nudging Ask regularly about this.
-R
But what should those addresses do when receiving a message?
- parrotbug: should open a RT ticket?
- status-ok: ?
- status-nok: should open a RT ticket?
Other things?
Anyone (Robert? :-) ) knows what per...@perl.org do?
Jerome
--
jqu...@mongueurs.net
Excuse me from stepping in, but I don't see why three adresses are
necessary. From my (limited) knowledge of RT, I thing that the parrot
bug address could create a ticket in the parrot queue, or add the mail
body to the appropriate ticket if the subject contains "[perl #XXXXX]"
-- then, it could close the ticket automatically if the subject matches
an OK report.
The big reason is to potentially reduce the load on the receiving end
of things. The OK and NOK messages may or may not go into an RT
ticket--it's perfectly reasonable to have them go to a custom front
end processor that picks out just the interesting bits, logs them,
and tosses the mail. (Tossing any mail that doesn't meet the criteria
we need) Mail to the bug address, OTOH, should open a ticket, which
means a lot more front-end processing, despamming, virus checking,
and whatnot.
Not that this *has* to be the way things are done, just that if we
split it out it *can* be done that way. Robert and Ask can direct all
three addresses to the same spot if they want. With the split they
just have more options available.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Yes. This is the new equivalent of bugs-parrot at rt.perl.org.
Use of that address should be phased out in favor of the new one.
> - status-ok: ?
> - status-nok: should open a RT ticket?
Right now both of these email addresses get dumped into files. We
need a "new system" (sigh) for processing these. It's a very
simple perl and database thing. We'll want to use it for perl5
and parrot.
(I wonder if we can just use CPAN testers for this?
http://testers.cpan.org/show/parrot.html)
> Anyone (Robert? :-) ) knows what per...@perl.org do?
A little too well.
-R