----- Original Message -----
From: Karen Etheridge <firstname.lastname@example.org
On Sun, Jul 07, 2013 at 02:45:22AM -0700, Ovid wrote:
Were I not so bandwidth-constrained, this would be less of an issue, but
I'd like to see a good Wiki page or something with the pro/con arguments
laid out. If this is too much, I should turn over maintainership to someone with
more bandwidth to ensure I'm not a blocker.
wiki page created:https://github.com/Perl-Toolchain-Gang/Test-Harness/wiki/TAP::Harness-and--the-w-flag
Thank you for putting that together. It made it much easier for me to follow this!
In Test::Harness, many people want to see -w no longer being enabled by default. Others object to this change because this alters the behavior and it we should tread carefully, particularly since this change effects everyone who installs modules. Backwards-incompatible changes to toolchain modules should generally not be done lightly. What's worse, different people have different desired behaviors here (mainly ribasushi, as far as I can tell, but I don't know what the silent masses think).
That being said, I tend to agree that -w should not be forced on those who do not want it.
1. Make the change.
2. Don't make the change.
3/4. Make this very easy to configure but keep/change the old behavior.
We have a change that people want, but as Eric pointed out, it introduces an incompatibility in the Test::Harness backwards-compatibility layer. If I'm to be conservative on this, I have to say that the one place we *don't* want incompatible changes is in a backwards-compatibility later!
I originally wrote TAP::Harness to be very configurable (we can argue later if I succeeded). Since Test::Harness is merely a compatibility layer on top of TAP::Harness, I like Eric Wilhelm's suggestion of software switching to TAP::Harness instead of Test::Harness. The basic change is simple. Instead of:
You do this:
my $harness = TAP::Harness->new( \%args );
Of course, the devil is in the details and I imagine that many tools will be more seriously impacted.
This allows us to maintain backwards-compatibility and gives uses a better interface, to boot!
The Real Question:
What toolchain software is being impacted by this and how hard would it be to make the switch? People have long known that TAP::Harness is a better alternative to Test::Harness, but the compatibility layer meant that people wouldn't have to make that switch right away. I suppose that some time in the past 5 1/2 years I should have been urging people to make the change. Perhaps now there is a reason to make that switch?
Admittedly, the above sounds like a remarkably self-serving way of passing the buck (very handy right now), but the question is very real: what are the obstacles to those wanting a different behavior in making a switch?