develooper Front page | perl.perl5.porters | Postings from June 2013

Re: I made t/podcheck.t less sensitive and fixed various pod issues

Thread Previous | Thread Next
David Golden
June 8, 2013 16:26
Re: I made t/podcheck.t less sensitive and fixed various pod issues
Message ID:
On Sat, Jun 8, 2013 at 11:45 AM, Aristotle Pagaltzis <> wrote:
> So the pumpking refused to say yes, to which you kept saying you really
> wanted to, then you went ahead and did it.

There several comments to the effect of "do what you like" --
specifically about whether to commit and then send an explanation or
send the explanation and wait.

> To paraphrase: “Shut up – unless the pumpking reverts it, I win.”
> Did I misunderstand?

Yes.  There are many committers.  Any of them can commit a patch.  If
there was a reasonable argument for doing something else, heck, I
might even commit it.

FWIW, "the only valid number is 79" is not a "reasonable argument" --
that's the personal preference.  Nor do I disagree with the rationale
for 79 as the goal -- only the choice of it as a cut-off for a
fail-ing lint test.

> Did I, in particular, miss any possibility that you will accept any
> argument besides open and active direct opposition by the pumpking?

I hope I just explained that.

> Yes, you have stated this position before. Do you also have something
> to say to Karl’s detailed objections, now that he has addressed several
> of these aforestated points (on *merit*, which you kept demanding) and
> shown some of your claims to be false, or at the very least debatable?

I didn't find anything that changes the fundamental difference of
opinion we seem to have about pod lint tests.

Karl claims that these tests are the equivalent of TODO and should be
kept for that reason.  They are not.  TODO tests warn but do not fail.
 These tests fail.  (Even *fixing* a known issue causes a fail.)

Pod fixes that he objects to I fixed because the test told me that
they were broken.  The fixes caused them to no longer be reported as
broken.  If the tests are good tests, then the fixes are good fixes.
If the fixes are bad fixes, then the tests are bad tests and should be
fixed or removed.  I have no objection to the latter conclusion.

> Judging by what has been written on both sides of this issue, it looks
> to me that had you wanted to do the right thing for Perl instead of just
> address your own desires, then you should have worked on splitting this
> up into build tests + optional lint tool – or should have left that work
> to someone else to do it that way

I *have* left that work for someone else to do that way.  Rather than
say "someone else should really fix thing along these lines" -- a
frequent pattern on p5p --  I've actually done the work to fix the
half that scratches my itch -- which is how volunteer-driven projects


David Golden <>
Take back your inbox! →
Twitter/IRC: @xdg

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About