chromatic chromatic at wgz.org writes:
Bogus to me is cannot install a dependency because, for all I can tell, the
tester has a space somewhere in a directory name somewhere in the path to
Perl and the tester's operating system and command shell just can't cope with
this.
That's well
On 3/14/06, Adam Kennedy [EMAIL PROTECTED] wrote:
It's just that the reporting system has a very limited view of what
should be stamped green, and what should be stamped red.
I've never like such breakdowns. Even adding only one more state/color
can make it a lot easier to interpret a result
Even better would be adding two more states so that you can
distinguish between prereq-failure, build-failure, test-failure and
ok.
Well actually I tried to sit down the other day and work out how many
distinct types of success/failure events there might be, for use in PITA.
The number
On Tue, Mar 14, 2006 at 23:04:02 +1100, Adam Kennedy wrote:
Even better would be adding two more states so that you can
distinguish between prereq-failure, build-failure, test-failure and
ok.
Well actually I tried to sit down the other day and work out how many
distinct types of
On 3/14/06, Adam Kennedy [EMAIL PROTECTED] wrote:
Even better would be adding two more states so that you can
distinguish between prereq-failure, build-failure, test-failure and
ok.
Well actually I tried to sit down the other day and work out how many
distinct types of success/failure
Adam Kennedy wrote:
Part of the problem comes in defining bogus.
This is a red herring. Consider the original proposal:
If a tester sends in a 'updated' report (matching all the appropriate
criteria), then the update should overwrite/mask the original.
There is no need to define the criteria
Hey! It's been over two months since we last had one of these suggestions!
I did battle with a module that shall remain nameless the other day. I
had a difficult time figuring out how to use it. In times like these, I
like being about to go to the build directory and p(aw|ore) through the
eg/
On Tue, Mar 14, 2006 at 04:52:18PM +0100, David Landgren wrote:
Hey! It's been over two months since we last had one of these suggestions!
I did battle with a module that shall remain nameless the other day. I
had a difficult time figuring out how to use it. In times like these, I
like
David Landgren wrote:
Hey! It's been over two months since we last had one of these suggestions!
I did battle with a module that shall remain nameless the other day. I
had a difficult time figuring out how to use it. In times like these, I
like being about to go to the build directory and
Moin,
David Landgren wrote:
Hey! It's been over two months since we last had one of these
suggestions!
I did battle with a module that shall remain nameless the other day.
I had a difficult time figuring out how to use it. In times like
these, I like being about to go to the build directory
Adam Kennedy wrote:
For all those component distributions I consider it a failure if it is
so complex that you need something more than just three or four lines
from the SYNOPSIS.
Maybe there should be a Kwalitee metric for the length of the synopsis?
:-)
Regards,
David Golden
Steve Peters wrote:
On Tue, Mar 14, 2006 at 04:52:18PM +0100, David Landgren wrote:
[...]
/eg scripts are a nice hands-on way of finding out how a module works
in real life.
No distribution should be without one!
Unless, of course, it has an examples/ directory, which would cause the
On Tue, Mar 14, 2006 at 12:48:52PM -0500, David Golden wrote:
Adam Kennedy wrote:
For all those component distributions I consider it a failure if it is
so complex that you need something more than just three or four lines
from the SYNOPSIS.
Maybe there should be a Kwalitee metric for the
Tels wrote:
Moin,
My modules are usually so feature crammed that they need a few examples
for showing what you can all do with it or to enable the user oto use the
modul without having to write/use perl code first.
Plus, the code cut and pasted from Synopses winds up with 8 space
leading
On Tue, 14 Mar 2006 16:52:18 +0100, David Landgren [EMAIL PROTECTED] wrote:
Hey! It's been over two months since we last had one of these suggestions!
I did battle with a module that shall remain nameless the other day. I
had a difficult time figuring out how to use it. In times like these,
* David Landgren [EMAIL PROTECTED] [2006-03-14 19:05]:
Plus, the code cut and pasted from Synopses winds up with 8
space leading indents or whatever, that you have to strip out
and/or you forget to turn off vi's auto indenting so you have
this massive staircase effect and the last line starts at
* David Landgren [EMAIL PROTECTED] [2006-03-14 16:55]:
No distribution should be without one!
Proc::Fork would definitely not benefit from an eg/ directory.
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
Steve Peters [EMAIL PROTECTED] wrote:
/eg scripts are a nice hands-on way of finding out how a module works
in real life.
No distribution should be without one!
Unless, of course, it has an examples/ directory, which would cause the
kwalitee test to fail. ;) I do think its a good
--- Tyler MacDonald wrote:
Well so far the only ones I've seen are eg, examples, and from that
renegade GD::Graph, samples.
And from that eccentric Acme::Bleach, demo.
/-\
On yahoo!7
Avatars: Dress up like your
On Tue, Mar 14, 2006 at 04:12:43PM -0500, David Golden wrote:
So back at the beginning of February, there was some email traffic about
how ActiveState's automated PPM build system was using an outdated
version of Scalar-List-Utils, which was causing a cascading prerequisite
failure for many
David Golden [EMAIL PROTECTED] wrote:
So back at the beginning of February, there was some email traffic about
how ActiveState's automated PPM build system was using an outdated
version of Scalar-List-Utils, which was causing a cascading prerequisite
failure for many distributions.
Has
David Golden wrote:
Steve Peters wrote:
The problem was that newer Scalar-List-Utils uses an internal Perl
function that Windows does not see as an exported function. This was
changed with Perl 5.8.8. Once ActiveState releases a Perl 5.8.8, they
should be able to upgrade the version of
Philippe M. Chiasson wrote:
It's not that simple a problem, exactly. The PPM build servers are all running
one the first ActivePerl release for that platform. That way, forward binary
compatibility can be guaranteed going forward.
I wondered if that was the cause of it. Still, that means
On Tue, 14 Mar 2006, David Golden wrote:
Steve Peters wrote:
The problem was that newer Scalar-List-Utils uses an internal Perl
function that Windows does not see as an exported function. This was
changed with Perl 5.8.8. Once ActiveState releases a Perl 5.8.8,
they should be able to
24 matches
Mail list logo
