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
From:
Ricardo Signes
Date:
June 11, 2013 12:20
Subject:
Re: I made t/podcheck.t less sensitive and fixed various pod issues
Message ID:
20130611121954.GA8629@cancer.codesimply.com
* David Golden <xdg@xdg.me> [2013-06-07T23:09:42]
> On Fri, Jun 7, 2013 at 10:10 PM, Ricardo Signes
> <perl.p5p@rjbs.manxome.org> wrote:
> >> The reason not to commit a likely contentious patch without prior
> >> vetting on p5p, is that it comes across as a power play designed to
> >> get one's way without regard to any merits.
> >
> > I was also unhappy with the way this commit was applied, and had
> > specifically said I wanted prior discussion.
> 
> And I replied that I didn't want to do work and then sit around
> waiting for weeks of bikeshed conversation that ultimately isn't about
> merits but is about personal preferences.

I feel like this situation is flying (with excruciating slowness) off the
handle.

Here is how I think I have contributed to the problem:

  * I said "if it comes down to '90, not 100' then I will pick a number and
    end the conversation."  I could've been clearer that I did not think 79
    versus 100 was the same kind of difference.

  * I said "do whatever you want, I guess," when what I really meant was, "I
    am very frustrated that you asked for objections and are not listening to
    my objection."  Once again I'm reminded to stop using sarcasm.

  * I made an irresponsible allusion to "saying FYIQ," which really never
    helps a single conversation.

For these bits of poor communication, I apologize.  I can and will do better.

To explain what got me so frustrated, allow me to quote two things from your
email:

> We have a version control system.  Commits are cheap and can be
> reverted.  If there is "consensus" to revert, then it can be reverted.
>  If not, then it can stay in.  It's just the flip side of waiting for
> "consensus" to apply a commit.
> 
> The discussion still happens, but the status quo is different, that's
> all.  If the discussion is about merits, then status quo is
> irrelevant.

...and...

> If everyone else wants a development culture in which whoever screams
> loudest for or against change gets their way[…]

There was some mention of the technical cost of the commits being published.
To that, I say "whatever."  It's not nothing, but it's not even close to
bothering me.  There is another cost, though, which I had tried (and, I think,
failed) to communicate on IRC:  pushing a change like this, when there is
probably going to be some disseent, especially from those who have already done
work on the code, is going to have a cost in morale.  In fact, Karl was unhappy
about the work being directly applied, and it's lead to this thread which is, I
think, probably more unpleasant for everybody than the technical pre-merge
discussion would've been.

...which brings me to the second snippet quoted above.  I said that I wanted us
to have discussions of potentially contentious changes before making them.  I
didn't say I wanted a screaming match.  It is unfair to suggest that I want
that.  In fact, I have said a number of times in the past that I think one of
my primary duties is to constrain discussions to be the right length and to
stay on topic.  I believe the solution to "too much petty bickering" is "better
discussions," not preemptive commits.  The latter leads to bad feelings and
edit wars, not a culture of teamwork and peer review.

I hope to have a branch in place that gets podcheck.t into a "middle ground"
state to consider in the next few days.

-- 
rjbs


Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About