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 14:32
Re: I made t/podcheck.t less sensitive and fixed various pod issues
Message ID:
On Sat, Jun 8, 2013 at 9:18 AM, Aristotle Pagaltzis <> wrote:
> So you asked the pumpking before pushing the commit, then?

IRC excerpt follows (unrelated discussions deleted):

18:32        xdg> rjbs, changing podcheck's max line to 100 and
dropping two "suggestions" about using L<> and F<> instead of C<>
eliminates about 90% of known issues
18:33        xdg> I'm also taking care of the remaining ones
18:34        xdg> Unless I hear violent objections in the next 30
minutes or so, I'll push all that work
18:36        xdg> that will give us fewer "false positives" in the future
18:55       rjbs> xdg: which suggestions?
18:59       rjbs> xdg: and by max line length, you mean of verbatim paragraphs?
19:00       rjbs> It's hard to know whether to violently object to "I
changed something."  You could always push it to a branch and then
say, "I think we should put this in blead."
19:01        xdg> rjbs, there are a lot of "maybe use L<> instead of
C<>" type suggestions
19:01        xdg> I think that level of linting shouldn't be in a porting test
19:01       rjbs> Oh, and the other "use F<>"?
19:01        xdg> yeah
19:02      leont> I can imagine the verbatim thing being semantically
useful, but the source line length thing not so much
19:02        xdg> my thought is that if we're not going to clean it
up, we shouldn't botehr to flag them
19:05        xdg> verbatim line 100 fixed most things.  a few more
could be easily broken
19:05        xdg> the rest -- about a dozen -- really just needed to
be left alone
19:07       rjbs> xdg: At the moment, it looks like a bunch of these
tests were added quite recently, by Karl.  16384ac1
19:07       rjbs> I think you should push your work to a branch and
point at it on list and see what Karl has to say.
19:08        xdg> rjbs, I'd rather just make the change and see if
anyone notices
19:08       rjbs> xdg: I will notice.
19:08        xdg> the last thing I want to do is have a line lenght
bikeshed argument
19:08  *    rjbs wonders whether this was discussed in 2011.
19:08       rjbs> xdg: If the argument is "90, not 100," I am happy to
say "get stuffed" and pick a number.
19:09       rjbs>
19:09      dipsy> [ podcheck.t revamp pushed to blead - Karl
Williamson - org.perl.perl5-porters - MarkMail ]
19:09       rjbs> Which, in turn, follows
19:09      dipsy> [ RFC: revamped podcheck.t - karl williamson -
org.perl.perl5-porters - MarkMail ]
19:10        xdg> If people are inclined to just --regen the known
issues list instead of fixing, then it's the wrong set of tests
19:11       rjbs> I agree.
19:12       rjbs> xdg: So presumably either Karl will say, "I agree,
this part of the overhaul is worth ditching," or, "actually fixing
this would be really useful because <something we don't know>"
19:12       rjbs> and we would get this explanation archived on the list
19:12       rjbs> which would then line up with searching the archives
by the time of the commit, which is how I just found the last two
19:13        xdg> How about I push it and announce it to the list.
Then discussion can follow from there for the record.
19:13       rjbs> do whatever you want, I guess
19:14        xdg> it avoids blocking on you to say "ok, fine, apply it"
19:14       rjbs> I think that is a lousy argument.
19:15       rjbs> I don't think I have done this in the past, and I
think you know exactly where to find me if I don't respond in a timely
19:15       rjbs> and it's not blocking on *me*
19:15        xdg> case 1: no one objects.... eventually I apply.  case
2: someone objects... there is debate... eventually you say 'apply' or
'don't'.  in more of those cases, the outcome is "apply"
19:15       rjbs> I didn't say I wanted to give it a stamp of
approval, btu that I thought there should be some chance for the list
to respond.
19:16       rjbs> I'm not sure what problem you are trying to solve.
19:16       rjbs> Keeping development velocity high?
19:17       rjbs> If you would rather revert than discuss, then fine.
19:17       rjbs> Do what you like.  I'm going to give a bath.
19:17        xdg> shiny.  :-)

Again, for the record, my position is as follows:

* the existing test was too sensitive -- there were too many thing
that people just regen'd into known issues and few looked at the known

* normative suggestions ("maybe use F<> instead" type comments)
shouldn't be fails and needed to be removed

* 79 characters is a good goal -- but this sort of linting should be
done outside a test (not unlike running valgrind) by those working to
fix it because it doesn't impact our readiness to ship

* setting a high bar (100 characters) to flag a few worst issues and
gradually tightening it as things are fixed will do more to encourage
fixes than an overwhelming list of offending lines

* I have no particular attachment to 100 characters -- it seemed a
good triage point that balanced between my preference to remove such
limits entirely and others desire to keep line length limits as a
fail-able test

* a line length bikeshed discussion on p5p is not a good use of anyone's time

I think the overall goal of reducing sensitivity has merit.  If enough
people object so strongly to 100 characters, then ask Rik said, "fine,
pick a number".


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