On Oct 7, 2014, at 2:42 PM, Paul Johnson wrote:
> In accordance with the terms of my grant from TPF this is the final report for
> my work on improving Devel::Cover.
Friggin’ awesome, thanks Paul!
Best,
David
smime.p7s
Description: S/MIME cryptographic signature
On Oct 24, 2012, at 10:15 AM, Karen Etheridge wrote:
> I'm theorizing (ha ha!) that David sent this to the wrong list, as it
> smells like something related to a private company. e.g. jira.iovation.com
> appears to be behind a firewall.
>
> They also appear to be hiring more QA :)
> http://iova
Hello QA,
The perl-module-rpms Git repository has had a number of changes since its last
promotion to production, including the addition of Sqitch. Please QA these for
production, as the history database project (née audit service) will require
it, as will many other projects coming down the pi
On Dec 5, 2011, at 5:59 PM, Leon Timmermans wrote:
>> *How* much longer? Does the upcoming MOP include syntax (class, method, role
>> keywords) and stuff like roles? Will one be able to drop Mouse in favor of
>> it?
>
> I just asked doy. It will support all of that, but not on older
> versions
On Dec 5, 2011, at 5:17 PM, Leon Timmermans wrote:
>> So, uhh... I'm going to go do a bad thing.
>
> What would be the repercussions of putting this in the fridge a little
> longer (I know, it's been in there for far too long already) and
> porting it to the upcoming mop?
*How* much longer? Does
On Nov 30, 2011, at 7:31 PM, brian d foy wrote:
> I'm not saying that you should dump Mouse, but when I see a design
> decision reach this far into the world (when nobody should have ever
> noticed it), I generally think it's time to consider if it was really a
> good idea. However, I have no expe
On Nov 29, 2011, at 9:39 PM, Michael G Schwern wrote:
> 1. The core gets a shrouded copy of Mouse::Tiny, with different
> namespaces, as discussed at the beginning.
>
> 2. TB2 gets a performance kick once Mouse is installed.
>
> 3. Extension authors can use Mouse to subclass TB2 and consume
>
On Nov 23, 2011, at 3:45 AM, Ovid wrote:
> But it's already broken in the mainstream Test::Builder. You just mean "keep
> it broken the way it is", right?
I’ll ignore getting into a semantic argument over your use of the word “broken”
(troll) and just say, “yes, please.”
David
On Nov 22, 2011, at 5:11 AM, Ovid wrote:
> Ah, just saw this. As I've already said privately, but maybe we can see how
> others feel, this is a PERFECT time to discourage use_ok and require_ok and
> even deprecate them (though I doubt we can remove them completely).
Feel free to discourage, yes
On Nov 15, 2011, at 6:43 AM, Jerry D. Hedden wrote:
>> Other than people writing test modules, who would find it useful?
>
> FWIW, threads and threads::shared use test.pl in their test
> suites. This seems to be historical and related to the fact
> that older versions of Test::More didn't work w
On Nov 4, 2011, at 1:58 AM, Steffen Schwigon wrote:
>>Dates: Friday March 30 - Sunday April 1st, 2012
>>Price: we have a quote for 5700 EUR for the three days
>> (this includes a 50% discount)
>>Seats: up to 50
>>Rooms: 3 to 4 available
>
> I am in in both cases. However
On May 24, 2011, at 9:18 AM, David Golden wrote:
> I doubt it. I have plans for an "application installer" that will
> pre-compute dependencies and reliably set up per-application lib
> directories. Different applications could have different versions of
> a module, but a single application will
On May 24, 2011, at 3:04 AM, David Golden wrote:
>> Or, if Net::Ping on the system is already 2.36
>> it will refuse to proceed?
>
> I think the current CPAN clients will all refuse to proceed. This is
> what I meant when I said that version ranges don't accomplish the goal
> because the compute
On May 23, 2011, at 11:52 AM, Jeffrey Thalhammer wrote:
> Historically, CPAN mirrors have always been static files. In other words,
> the paths in the 02packages file always pointed directly to some physical
> file on disk. This made it possible to access mirrors the with the older
> ftp:// a
On May 20, 2011, at 11:04 AM, Jeffrey Thalhammer wrote:
> I'm not attempting to build an all-encompasing dependency management system.
> I've tried to avoid thinking about it in terms of CPAN as we know it, since
> in theory, that is an implementation detail. But in practice, I'm will
> stipu
On May 20, 2011, at 3:51 AM, Jeffrey Thalhammer wrote:
> Once again, I'm faced with building another private CPAN. But this time, I
> have an opportunity to build something that could have broader appeal in the
> Perl community. In fact, the explicit goal is to produce an open source,
> turnke
On Aug 10, 2010, at 12:33 PM, Andy Lester wrote:
> I know that there is stuff that is pending, questions to be answered about
> something in the T::H toolchain. Is there anything in there that precludes
> Andy releasing a version of T::H now?
>
> I've got projects depending on patches I submit
On Jul 15, 2010, at 2:02 PM, Andy Lester wrote:
> This whole SourceHandler looks much more like the Right Way To Do It.
Yes.
> I wish Mr. Armstrong were around for discussion.
What's your question? (Andy's probably asleep, given that he lives in GMT.)
Best,
David
On Jul 15, 2010, at 10:26 AM, Andy Lester wrote:
> I've got a dispatch script that runs either .t under perl or .phpt under PHP.
> Basically I've been running:
>
> prove --exec='/home/alester/smoke/bin/smoke-dispatch' --ext=.t
>
> and it's been just fine. It just never gets called by an
On Jul 15, 2010, at 10:06 AM, Andy Lester wrote:
> Might be that simple, but I don't know the guts of prove any more. That's
> why I asked. I didn't want to make this a CYJ.
Camp Young Judea???
>> But then you'll need to write a PHP handler. Brief intro:
>>
>> http://www.justatheory.com/comp
On Jul 15, 2010, at 9:12 AM, Andy Lester wrote:
> Can we discuss the ways that we might get prove to recognize more than one
> extension?
>
> Right now, I can say
>
> prove --ext=.phpt --exec=/usr/local/bin/php
>
> but I can't say
>
> prove --ext=.phpt --ext=.t --exec=/usr/local/b
On Aug 1, 2009, at 7:59 AM, David Golden wrote:
Wow, putting them in MANIFEST.skip - what a simple and great
idea. :) I
don't even need the environment variable in that case. Anyone who
is running
'make test' in the git source will see the internal tests, as they
should...anyone who has the
On Jul 31, 2009, at 11:32 AM, Jonathan Swartz wrote:
I've also started moving the tests themselves from MANIFEST to
MANIFEST.skip
Wow, putting them in MANIFEST.skip - what a simple and great
idea. :) I don't even need the environment variable in that case.
Anyone who is running 'make test
On Jul 7, 2009, at 7:47 AM, Erik Osheim wrote:
Well, I suppose it's better that I sent the wrong tarball here, rather
than uploading it to CPAN, but it's still embarrassing.
Anyway, I created a new tarball (using ./Build dist; thanks for that
tip) and am attaching it.
Looks interesting. I'm n
On Jul 2, 2009, at 3:32 AM, Rafael Garcia-Suarez wrote:
2009/7/2 Paul Fenwick :
Since the line in question is using diag(), it already does have a #
prepended to it. AFAIK most TAP parses pass that through to the
user by
default.
diag() writes to STDERR by default, so it's noisy and clutt
On Jun 30, 2009, at 12:13 AM, Ovid wrote:
And that would potentially have issues when it assigns "\t" to $name
and -12 to $age, even those are both valid values for the types in
question. It would be very difficult to find data which
automatically fits any random type, but it could be writ
On Jun 29, 2009, at 12:39 PM, Ovid wrote:
if the 'some subtest' subtest didn't emit anything until
that summary 'ok 1' line, can we safely run subtests in parallel
without worrying about whether or not their output overlaps?
Not unless you can put a lock on the file handle. Or, I guess, you
On Jun 29, 2009, at 9:50 AM, Ovid wrote:
And Test::Exception and many, many other Test:: modules. It's a
very common pattern and getting all authors to agree to fix those
modules is a dubious strategy, I think.
/me shrug. If their modules fail with a new version of T::B, they have
to fix
On Jun 29, 2009, at 2:19 AM, Ovid wrote:
my $Test = Test::Builder->new;
If every test function simply had that line in the function, rather
than trying to share this across all test functions, the code would
work fine.
Not sure of the best way of handling this, but it's annoying as
h
On Jun 28, 2009, at 2:20 AM, Ovid wrote:
That led to the following very delightful output to my terminal:
I like! I'm going to do something like this to support running
JavaScript tests in multiple browsers.
Best,
David
On Jun 24, 2009, at 9:59 PM, David Golden wrote:
As long as we're bike-shedding, a simplification:
subtest {
plan "sanity check" => 3;
pass for 1 .. 3;
}
Anything other than "no_plan" or "skip_all" is taken as if "tests".
I thought of that and dismissed it, but seeing it in print…get
On Jun 24, 2009, at 8:32 PM, Michael G Schwern wrote:
subtest {
name 'text';
pass;
};
That's interesting, though I don't think its worthwhile as the name
is serving
a dual purpose as mentioned above. It's not just the name of the
subtest but
also explaining what the su
On Jun 23, 2009, at 2:22 PM, Paul Johnson wrote:
One question though. Why
subtest "text", sub {};
rather than
subtest {}, "text";
?
The latter seems more consistent as well as removing a rather
annoying bit of
syntax. Were you worried that "text" might get lost at the end of
the
I did all I could to stop it, but it just wasn't possible. pgTAP 0.20
has somehow made its way from my Subversion server and infiltrated the
PostgreSQL community. Can nothing be done to stop this menace? Its use
leads to cleaner, more stable, and more-safely refctored code. This
insanity mu
That information should be in the wiki.
Best,
David
On Feb 24, 2009, at 12:41 PM, Andy Lester wrote:
Should someone other than me be owning and maintaining TAP.pm?
And if so, here's something to go in.
xoa
Begin forwarded message:
From: Frank van Dijk
Date: February 24, 2009 2:13:03 PM
On Feb 23, 2009, at 1:39 AM, Aristotle Pagaltzis wrote:
Or differently, to RSS?
It may well be that we’ll need to break backcompat over this
issue, and if so, OK, but “I don’t care about backcompat” is
no way to go about designing a format that succeeds widely.
Hence my suggestion for a depre
On Feb 22, 2009, at 3:45 PM, Michael G Schwern wrote:
I think that second one has value.
Agreed, but that's what a deprecation cycle is for.
TAP currently has no deprecation cycle. That's what I introduced
earlier.
http://www.ietf.org/mail-archive/web/tap/current/msg00411.html
Good!
D
On Feb 21, 2009, at 10:54 PM, Michael G Schwern wrote:
There is Perl 5 style backwards compatibility where you never, ever
break
anything for years and years and years and even for code that you're
not sure
even exists. That's what chromatic is on about.
And then there's backwards compatib
On Feb 21, 2009, at 5:44 PM, Michael G Schwern wrote:
Yeah, I'm suggesting this more for a new version of TAP.
It won't work because it's not backwards compatible.
I care less and less about backwards compatibility every day. Also,
chromatic.
Technically "ok 1.1" should be read as an unn
On Feb 21, 2009, at 11:35 AM, Michael G Schwern wrote:
David E. Wheeler wrote:
Dot notation?
ok 1.1
ok 1.2
ok 2.1
1..2
If you don't want any existing TAP parser to be able to read it and
delay
release until they do, sure!
I am totally not waiting for TAP to work out sub-plan s
On Feb 20, 2009, at 12:34 PM, Andy Armstrong wrote:
Yeah, I think that's reasonable - although it would be nice at some
point to do something about the option proliferation that seems to
afflict us. That's not your fault of course :)
Thanks.
You you should probably subscribe to
http://ww
On Feb 20, 2009, at 12:34 PM, Andy Armstrong wrote:
Yeah, I think that's reasonable - although it would be nice at some
point to do something about the option proliferation that seems to
afflict us. That's not your fault of course :)
Thanks.
You you should probably subscribe to
http://w
On Feb 20, 2009, at 1:23 PM, Gabor Szabo wrote:
I wonder if there are modules out there that already do this?
I could not find any that would fit my needs.
Test::Output?
http://search.cpan.org/perldoc?Test::Output
If it doesn't capture output from other programs, have a look at
Capture::
On Feb 20, 2009, at 10:20 AM, Andy Armstrong wrote:
On 20 Feb 2009, at 16:52, David E. Wheeler wrote:
On Feb 20, 2009, at 3:18 AM, Andy Armstrong wrote:
RENUMBER
Won't that fuck up existing users of the library?
Yeah, I was making a BASIC joke :)
The description for verbose s
On Feb 20, 2009, at 3:18 AM, Andy Armstrong wrote:
RENUMBER
Won't that fuck up existing users of the library?
The description for verbose should really be "show the raw TAP
stream".
Patches / commits welcome - but I'm not going to have time to do
anything more than review said patches /
On Feb 19, 2009, at 1:16 PM, Michael G Schwern wrote:
What prove is referring to in -1 is suppressing its own messages
about test
failure, not TAP comments.
Ah, okay.
What you want is a .5 (didn't we figure out in BASIC that you don't
closely
space your numeric sequences?) which is "show
On Feb 19, 2009, at 1:29 PM, David E. Wheeler wrote:
TAP::Harness->new({
verbosity => $opts->{verbose} || $ENV{TEST_VERBOSE},
timer => $opts->{timer},
color => $opts->{color},
exec => ['psql', '-c'],
})->runtests('SELEC
On Jan 26, 2009, at 10:54 PM, David E. Wheeler wrote:
TAP::Harness->new({
verbosity => $opts->{verbose} || $ENV{TEST_VERBOSE},
timer => $opts->{timer},
color => $opts->{color},
exec => ['psql', '-c' 'SELECT * FROM tap.run
On Feb 19, 2009, at 10:07 AM, David E. Wheeler wrote:
As a way of dealing with the immediate need, I'd love to see a way
to just tell TAP::Harness to emit all diagnostics, whether failure
diagnostics or freeform output, as you say. It should be off by
default, as you pointed out i
On Feb 19, 2009, at 12:12 PM, Michael G Schwern wrote:
I’m not talking about pass/fail, I’m talking about finding out
about subplans, from the consumer end.
As TAP has no formal means to express that, and I'm not waiting for
a TAP
extension, any TAP reader will need extra logic to figure tha
On Feb 19, 2009, at 3:55 AM, Andy Armstrong wrote:
One proposed solution is the TAP logging syntax, but it wasn't
discussed at the TAP summit in Oslo last year. It's status is in
limbo. http://testanything.org/wiki/index.php/TAP_logging_syntax
OK - let's move on that then.
That could take a
On Feb 18, 2009, at 3:57 PM, Aristotle Pagaltzis wrote:
Shouldn’t this be fixed?
Sure, but how?
I don’t know.
But injecting artificial test results seems like a fairly big
modification to the format’s semantics to me, and I’m not
comfortable with the idea of doing that for no greater reason
On Feb 18, 2009, at 2:44 PM, Michael G Schwern wrote:
Sending comments to STDOUT has been the standard way of hiding
comments from
the user for a long time. If we started displaying them by default,
suddenly
silently passing tests would start spewing all sorts of random junk
violating
the
On Feb 18, 2009, at 2:04 PM, David E. Wheeler wrote:
Of course if I use -v, it passes `verbosity => 1` to TAP::Harness,
but I'd love to be able to see the failure diagnostics without
having to see all of the passing test TAP output, too. Is there some
way to get TAP::Harness
Howdy,
When I run prove/TAP::Harness against a Perl test, I can see failures
even when not using verbose mode because, IIRC, that data is sent to
STDERR and ignored by TAP::Harness:
prove t/base.t
t/base1/316
# Failed test '... And now strict is turned on'
# at t/base.t line 34.
#
On Feb 5, 2009, at 6:23 PM, Michael G Schwern wrote:
# Planning 2 more tests at foo.t line 3.
ok 1 - First test
not ok 2 - 2 tests were planned but only 1 was run
# Failed test "2 tests were planned but only 1 was run"
# at foo.t line 6.
# Planning 1 more test at foo.t line 6.
ok 3 - Seco
On Feb 5, 2009, at 12:34 PM, Michael G Schwern wrote:
Though we don't have incremental TAP plans, Test::Builder can check
that
you've run all the tests you said you'd run before you add more.
Thus...
use Test::More;
plan add => 2;
pass;
plan add => 1;
pass; # failure
pass
On Feb 4, 2009, at 3:15 PM, Ovid wrote:
Only one. The BBC frowns on it if you come back *completely*
wasted. I'd probably get a stern talking to if I did.
Ooh, scary.
D
On Feb 4, 2009, at 6:35 AM, Ovid wrote:
Thoughts?
(The first idea is bugging me because I swear I had thought of a
show-stopper over lunch, but for the life of me, I can't recall what
it was).
Must've been a damn good lunch. How many pints did you kill?
D
Howdy,
This is for Any Armstrong, primarily, but someone else might know the
answer, or be interested, anyway.
I added xUnit-style test programming to pgTAP recently. What this
means is that, rather than putting tests in a .sql test file, a
developer can define a function that returns the
On Jan 23, 2009, at 11:25 PM, Michael G Schwern wrote:
I don't cut off and discard the ends of roasts, either.
You would if you were still using the same pot your grandma was
using, which
we mostly are.
Dude, does your grandma deal? Sounds like really good stuff.
David
On Jan 23, 2009, at 10:23 AM, Eric Wilhelm wrote:
I don't recall claiming that it was *simpler*. The single static
numeric plan is simplistic. Given any cross-platform skip issue or
optional-dependency condition, you have a situation where the plan
becomes harder for a human to get right. In
On Jan 23, 2009, at 10:18 AM, Fergal Daly wrote:
With nesting, you can move some aspects of the plan closer to the code
(which is good) but you must always have some part of the plan far
enough away from the code so that it is not subject to the same bugs.
Ideally something like this would work
On Jan 23, 2009, at 1:11 AM, Eric Wilhelm wrote:
If so, you're using the plan as something like a stand-in for the
assertion:
my @resources = $manager->resources;
is(scalar(@resources), 12, "have 12 resources");
And actually, you probably want to assert something like:
my @resources = $man
On Jan 22, 2009, at 11:22 PM, Ovid wrote:
Well, since the thread was about Eric's method of eliminating
'plan', after you made your explanation, I think it was clear that
the proposal would require, as Eric suggested, an alteration to core
TAP:
ok 1
ok 2
ok 1
ok 2
ok 3
On Jan 22, 2009, at 10:02 PM, Andy Lester wrote:
On Jan 22, 2009, at 11:23 PM, David E. Wheeler wrote:
people see Perl 6 as an opportunity to rethink things.
Except that Perl 6 isn't changing TAP.
No, but there really wasn't any talk about changing TAP in that
thread. It w
On Jan 22, 2009, at 7:04 PM, Andy Lester wrote:
Please, can we stop going over plans again?
Every minute spent yapping about whether plans are good or not is a
minute that could be spent doing something useful, like working on
Test.pm for Perl 6.
You're going to have to be a bit tolerant
On Jan 22, 2009, at 5:22 PM, Michael G Schwern wrote:
Because, in Perl and other languages, until you run it you can't
know what
class $object is going to be, or what its inheritance tree will look
like, and
once you do figure out which run_tests() will run (if any) you're
back to the
prob
On Jan 22, 2009, at 2:24 PM, Eric Wilhelm wrote:
Or thereabouts. The business of skipping, todoing, counting,
planning,
and ensuring that all tests actually run is going to involve various
details and possibly even get into the limitations of TAP -- but you
now have every chunk of tests setup
On Jan 22, 2009, at 1:08 PM, Fergal Daly wrote:
Assuming the static analysis was correct, it would always produce the
correct number thus would be equivalent to no_plan. For me, the
purpose of the plan is not to detect failures that cause early exits -
it can do that but the test harness also lo
On Jan 22, 2009, at 11:06 AM, Eric Wilhelm wrote:
That still doesn't imply that we can't somehow count the number of
tests
with a computer instead of relying on humans to screw it up. If some
combination of static analysis and early runtime can come up with a
count, then it becomes possible t
On Jan 21, 2009, at 2:13 PM, Ovid wrote:
... is because we want a default value of 1 for the number of tests
to skip. Eliminate that default and the entire problem goes away.
You must *always* specify the number of tests to skip. $reason is
optional.
Sound good?
Yes, but can the numbe
On Jan 21, 2009, at 10:47 AM, Ovid wrote:
However, that's going to break if $count is a string, right?
Thought this might work as a heuristic for that third definition:
# Won't get called unless the string has a non-digit in it
multisub skip( Str $desc where { $desc ~~ /\D/ } );
Thus, you
On Dec 12, 2008, at 3:41 AM, Eric Wilhelm wrote:
I've just committed (svn r12149) David Wheeler's change to enable
check
subroutines on properties in Module::Build, which is now used to
validate the installdirs property.
Ah, great. Looks like you committed it as submitted, yes? Did you
cha
On Dec 8, 2008, at 3:30 PM, Barbie wrote:
The latest in the family of CPAN Testers websites has been officially
launched today. The CPAN Testers Preferences Administration website is
for authors to determine their own preferences for the CPAN Testers
reports and summaries.
https://prefs.cpantes
On Oct 28, 2008, at 05:29, Ovid wrote:
Just a quick cultural point: over here in the UK, "cunts" is a very
common term and while insulting, is nowhere near the "OH MY GOD WHAT
DID HE JUST SAY?" level of unacceptability in the US. Since many
reading this list are in the US, they might have
On Sep 20, 2008, at 00:29, Barbie wrote:
See http://use.perl.org/~barbie/journal/37496 for all the gory
details.
Barbie++ # Thank you!
David
On Sep 18, 2008, at 16:12, David E. Wheeler wrote:
Howdy,
I've released a new version of pgTAP, 0.10. Grab it here:
http://pgfoundry.org/frs/?group_id=1000389
Changes mainly include lots of new functions for testing a schema
(has_table(), has_view(), has_col(), has_pk(), h
Howdy,
I've released a new version of pgTAP, 0.10. Grab it here:
http://pgfoundry.org/frs/?group_id=1000389
Changes mainly include lots of new functions for testing a schema
(has_table(), has_view(), has_col(), has_pk(), has_fk(), col_is_pk(),
col_is_fk(), fk_ok(), etc.) and portability a
On Sep 17, 2008, at 17:51, Michael G Schwern wrote:
I think that you can add TAP columns for JavaScript and PHP, too, no?
Yeah, and so can you. :P
Someone beat me to it for PHP, but I added a TAP column for
JavaScript, along with a link to Test.Simple.
Now if only we could get OpenJSAN a
On Sep 17, 2008, at 13:24, Michael G Schwern wrote:
FWIW I added a TAP column to the Perl section on Wikipedia's list of
unit
testing frameworks. If every testing framework has to sound off on
xUnit, why
not TAP?
http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#Perl
I think th
On Sep 11, 2008, at 15:18, Michael G Schwern wrote:
There also doesn't appear to be a way to get just the failures so I
have to
figure out how to twiddle my RSS reader to filter out the passes.
Barbie says he's worked in a patch from me that will allow you to
subscribe to a feed with only
On Sep 11, 2008, at 14:17, Michael G Schwern wrote:
Because they all come in at one lump, I have to deal with them in
one lump.
There's no easy system to tell which ones I've dealt with
(previously I'd just
delete the mail) and which ones I haven't.
The way it looks right now, I want my CC'
On Sep 11, 2008, at 10:47, Andy Armstrong wrote:
According to svn blame:
470 andy sub summary {
481 andy my ( $self, $aggregate ) = @_;
791 andy
754 andy return if $self->silent;
So I'd say the summary it's been there for a while :)
(we're currently up
On Sep 11, 2008, at 05:09, Andy Armstrong wrote:
On 8 Aug 2008, at 20:46, David E. Wheeler wrote:
I've started fiddling with the stdout option to TAP::Harness. It's
nice, although it doesn't capture everything. I mean, I think it
does, but stuff still gets sent to STDOUT, to
On Sep 10, 2008, at 10:30, Eric Wilhelm wrote:
Yes. Please let's not start cutting the ends off of the ham just so
we
can get mom's old pan out of the attic.
Why is there a ham in the pot in the attic? Must be a bit rotten.
Best,
David
On Sep 8, 2008, at 03:49, Ovid wrote:
In the developer release of Test::Simple, Test::Builder has been
altered to die if you have any arguments after 'no_plan'. This
means that some previously passing tests will fail. In fact, there
are two test programs in Moose 0.57 which have this and
On Sep 6, 2008, at 15:47, Michael G Schwern wrote:
* Changed the message for extra tests run to show the number of
tests run
rather than the number extra to avoid the user having to do
mental math.
[rt.cpan.org 7022]
Smart. I've updated Test.Simple and pgTAP with this change,
On Sep 6, 2008, at 00:00, Barbie wrote:
The patch that David Wheeler has written for an RSS feed for no PASSes
has already been included into the new report site. The launch of the
site has been put on hold, while I sort out the new mailer. Further
RSS
may become available after the current r
On Sep 5, 2008, at 18:17, chromatic wrote:
Hm. What's your thought on turning that into something which a
Module::Build
or ExtUtils::MakeMaker plugin could run on ./Build distcheck or make
distcheck?
I'm happy to write the Module::Build plugin, if anyone else might
find this
idea useful.
On Sep 5, 2008, at 12:08, David Golden wrote:
There is sufficient outrage now over email volumes that waiting for
the preference system seems pointless and hopefully, in exchange for
quick action now, those that are most annoyed will be willing to be
patient during the transition from opt-out to
On Sep 5, 2008, at 11:36, chromatic wrote:
They are annoying, but I'm not sure it's my biggest complaint.
There's also
the arbitrariness of the upload/debug/revise cycle of trying to
please a
black box full of testers. I'm not willing to say that this is
primarily the
fault of CPAN Teste
On Sep 5, 2008, at 11:28, Andy Lester wrote:
Getting fail report emails is annoying and should be changed to be
opt-in. Would that solve your problem?
Oh, and yes. Once we stop spamming people, CPAN Testers then
becomes the Consumer Reports model, not the police model.
Thank you. I think
On Sep 5, 2008, at 10:57, chromatic wrote:
Full credit (and many thanks) to David Golden and others who are
moving away
from this model, but if I'm an ass for saying "You know, that has a
lot in
common with spam" and "CPAN-related services with good intentions
should
carefully consider the
On Sep 5, 2008, at 11:27, Andy Lester wrote:
On Sep 5, 2008, at 12:24 PM, David E. Wheeler wrote:
Punishing? Punishing would be removing a module from CPAN. Getting
fail report emails is annoying and should be changed to be opt-in.
Would that solve your problem?
One person's &quo
On Sep 5, 2008, at 10:46, chromatic wrote:
I don't like the check testers/grumble/upload new distribution with no
functional changes just niggly little packaging bits you hope will
opt out of
testers tests you don't care about/sleep/repeat cycle. It's a slow,
clunky
black box game where the
On Sep 5, 2008, at 10:32, chromatic wrote:
You're right, there's no "compel". If reports don't come by email
to people
who haven't asked for them, then they'll only get reported via an
RSS feed I
can choose to read or not, and on the search.cpan.org pages of my
distributions, which I don't
On Sep 5, 2008, at 09:34, Andy Lester wrote:
Well, yeah, I have too. And sometimes I make a tweak to get things
working on 5.005, and other times I tell my users that it runs 5.006
or later by saying so in Build.PL. Seems reasonable to me to specify
such dependencies.
"Seems reasonable to me"
On Sep 5, 2008, at 09:13, Andy Lester wrote:
"Here are test reports reporting on failures for these things that
we care about you caring about."
Again, this is CPANTS, not CPAN Testers.
Getting failure reports for a module not running on Perl 5.005 is a
test
about something I don't care a
On Sep 5, 2008, at 09:10, Andy Lester wrote:
I'd hate to lose those in my email because other people don't want to
filter their mail.
I'd hate to get spammed because other people don't want to sign up to
receive them.
I think that adding changing things so that authors opt-in to getting
re
1 - 100 of 156 matches
Mail list logo
