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
From:
David Golden
Date:
June 8, 2013 14:32
Subject:
Re: I made t/podcheck.t less sensitive and fixed various pod issues
Message ID:
CAOeq1c8=RAPY70d3xqetdPAkXnkPEc_SncvTNiMJhRNEGezNZg@mail.gmail.com
On Sat, Jun 8, 2013 at 9:18 AM, Aristotle Pagaltzis <pagaltzis@gmx.de> 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> http://markmail.org/message/72dstim35bjl3fna
19:09 dipsy> [ podcheck.t revamp pushed to blead - Karl
Williamson - org.perl.perl5-porters - MarkMail ]
19:09 rjbs> Which, in turn, follows
http://markmail.org/thread/p3mxaxwxjn7vpupb
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
messages
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
way.
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
issues
* 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
--
David Golden <xdg@xdg.me>
Take back your inbox! → http://www.bunchmail.com/
Twitter/IRC: @xdg
Thread Previous
|
Thread Next