The email I didn't want to write.

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

The email I didn't want to write.

Matt S Trout-2
(I've been absent from the discussion since sunday night because I've been
thinking through and then writing this up; please believe me when I say that
I really didn't enjoy the process, but could no longer see how to avoid it)

So, up until a few days ago, the conversation seemed to be about establishing
a new team, and figuring out how we make that team accountable, and then
moving forwards from there.

Now, of course, it's going to be about "do we establish a new team, or do
we accept ribasushi's offer to continue part-time as dictator?".

Which means now rather than giving riba the send-off-with-applause that his
technical contributors have more than earned him, I'm going to have to talk
about the policy and human factors issues that exist around DBIx::Class and
its place in the greater CPAN ecosystem, because otherwise there's going to
be no way I'm going to feel like the userbase is making an informed decision.

And, y'know, letting you lot make an informed decision was exactly what led
me to ask riba to explain his plans in the first place, even though before I
made a start I was already pretty much expecting that the response would be
an attempt to paint me as satan.

Which, well, https://twitter.com/ribasushi/status/776259074497323008 - I'm
pretty sure "rabid badger" wasn't intended as a compliment.

Happily (from my POV, at least) his position was that his right to
unilaterally repudiate a previous agreement over permissions with a PAUSE
admin (which I'd've documented publically had I known then what I know now,
but at the time figured was quite sufficient given I was dealing with a
partner in crime and close friend who I trusted to keep their word) was based
on moral authority derived from the support of the DBIC userbase, and so the
PAUSE administration insisted that you actually be consulted.

Of course, that didn't mean actually revealing a plan, but instead
complaining that being expected to consult with the userbase was evil
and terrible and somehow made it impossible to have a plan at all. But it
was engagement at least.

Now, however, as of https://twitter.com/ribasushi/status/790515094685876224
there is sort of a plan.

The trouble is it's at least as risky as mine is, albeit along different axes.

If this was ribasushi-of-2012, say, I'd be inclined to say "I'm not sure
why you want to drop everybody else's co-maints, but otherwise I'm totally
happy with you staying in charge indefinitely". However, it isn't.

http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/012282.html

gets one thing right - my views on stability haven't changed a lot since
2005. In that I care about it rather a lot, but refuse to consider it the
only factor.

Thing is, these days riba's views are rather more absolutist than that, and
involve branding anybody who doesn't value it exactly as much as he does as
(variously) irresponsible, incompetent or malicious.

We had a long chat at one point about the idea that accusing somebody of
active malice towards their userbase over a technical disagreement (in this
case fatal warnings, which, roughly, I love because I'm more worried about
code 'completing' but doing the wrong thing are thereby causing data loss or
corruption, and riba hates because he's more worried about code throwing
unexpected exceptions in cases that would've worked fine otherwise ... and
thereby causing data loss or corruption) is ... not only probably not the
case, but even if it is, actively counterproductive. In the end, in this
particular case, it became clear that most people found fatal warnings an
unpleasant default and while I continue to encourage people to try them out,
I'm comfortable that they'll never be universally loved.

Thing is, the amount of bile directed at me during the process basically made
me avoid the entire thing for about six months because I was sufficiently
upset by the accusations of malice that, frankly, something else always seemed
a more interesting thing to spend my weekend on. This significantly delayed
my concluding I was wrong and fixing my mistake, to the detriment of users.

Those who've known me over the years are probably aware that I'm both thicker
skinned than average and also more comfortable being blunt (sometimes to the
point of accidental assholery) than average - so it shouldn't surprise you to
know that the same effect happens when other people are treated the same way.

Hell, I know I've accidentally driven people off with overly heated
arguments. But I consider that to be a bug in my argument process since on
a human level it's toxic to the contributor group and on a techical level
it usually means things take even longer to get fixed. riba-of-2016 doesn't
seem to see that as a problem at all that I can tell.

Back in May, he added comments to the source code directly attacking rjbs
for the crime of disgreeing with him technically, and when ilmari and I
suggested this wasn't really acceptable, he posted

http://lists.scsys.co.uk/pipermail/dbix-class/2016-May/012164.html

to the mailing list and then walked out of the #dbic-cabal channel; happily,
the following day he quietly removed the comments in

https://github.com/dbsrgits/dbix-class/commit/e8452b02f9db53148f3d0bc6679a107a9c956174

but you will, of course, notice that in spite of being a long time DBIC user
albeit no longer pumpking, rjbs' voice has been absent from this discussion.

That 4/5 email struck me as, frankly, jaw dropping. The attacks on me I
figured were inevitable but lashing out at ilmari and castaway as well, not
so much.

"loses interest whenever the problem space required a more in-depth solution"

This seems like a surprising description of ilmari, given he holds the
first-come permissions for both DBIx::Class::Schema::Loader and SQL::Abstract
and conducted a huge and highly successful refactor of the former. I've
always found him to, in fact, be somebody once can happily spend hours
discussing in-depth solutions to hard problems ... so I rather suspect that
if that's riba's experience of his work of late, the reason for loss of
interest in those cases is more about treatment than technical effort.

One of the things I think makes a difference here is that I love mentoring
people, and helping them level up, and getting them to re-work their code
until they can be proud of it even if that takes much longer than re-writing
it myself would've done, and generally riba seems to find that a much more
energy consuming process than I do.

The thing is, if you don't do that, you don't grow a sustainable team. When
ether first started releasing toolchain level code, there was some carnage
... which she generally had corrected within a day or two, and which she
rapidly took as feedback to adjust her style to be more conservative. These
days, she's not only maintaining/releasing quite a few things - see
https://metacpan.org/author/ETHER - but is generally part of the arguments
in favour of being relatively conversative and has been helping newer
recruits learn the same lessons.

DBIx::Class, on the other hand, hit the "no co-maintainers and no successor"
wall, and given just how much fun this has been for everybody I hope it's
understandable if I think taking steps so that doesn't happen again would
be a good idea (hence my governance proposal being explicitly designed to
just turning me into a new SPOF).

Meanwhile, we've now reached a point where seeing a ticket or patch sent in
by ribasushi tends to result in people ignoring it for a few days because
they need to work up the emotional stoicism required to deal with the chances
of it being a useful patch/ticket that happens to come with a free polemic.

Plus his tendency to refuse to compromise or believe in consensus tends to
harden other people's attitudes, resulting in a number of fights between us
that boiled down to "riba will accept no compromise because that would mean
endorsing an imperfect solution, mst would prefer to get as many concessions
as he can to stability and then endorse the result". So ironically, his
disappearance from those discussions as of more recently has actually made
it easier to shift things overall in the direction of stability, in spite of
losing somebody who I used to basically rely on having on my side in such
discussions.

I believe on previous occasions riba's crystallised this as "open source
is about the users, not us", and considered technical excellence to be the
only thing of relevance in how a project is run. The thing is, I don't
really think open source is *about* the people developing as such. What I
think is that open source is *made of* the people developing it, because
if you don't build a team around a project it ends up with a bus factor of
one, and a project like DBIx::Class is sufficiently important that that
simply isn't safe.

So, roughly, we're looking at a choice between

- a cathedral type approach
- run by the single most effective committer we've ever had
- but part time
- with no team, and likely no team going forwards, leaving the bus number at 1
- although riba-and-only-riba will be amazingly free of bugs
- who's actively attacked and/or alienated the owners of many of our downstream
  dependencies, including the crucial SQL::Abstract
- who didn't even think the userbase needed to be consulted about this

(and obviously given riba's explicit insistence that I be run out of town on
a rail, there's no way I could credibly start a DBIC2, so I'm afraid anybody
who wants a fork needs to make sure they've got somebody to run it first)

versus

- a bazaar type approach
- run by people who've all got noticeable amounts of code in the system
- but aren't currently nearly as familiar with the internals
- intending to build out a team of contributors, which will almost certainly
  mean that at some point somebody will screw up and we'll have to scramble
  to do a bugfix release
- but that's how you get the bus number up if you want a sustainable project
- who're well known and (with the partial exception of me) well liked among
  the maintainers of the projects we're dependent upon
- who intend to operate under a system where if we do screw up, the userbase
  have an explicit mechanism to hold us to account

(and we can, internally, run a two-stream development system where people
opt-in to a version of DBIx::Class with new features but probably also new
bugs, and changes migrate down to the main stable release over time - this
can be done without disrupting the ecosystem, I think; pulling the same trick
off as a fork may be trickier)

Both plans have their risks, definitely. I have an opinion as to which plan's
risks scare me less overall, obviously.

I'm off to Cluj tomorrow and so I'm not sure when I'll be able to get an
updated governance proposal together - hopefully by monday if not sooner.

This email is intended to both communicate my reservations about the
part-time-riba plan, such that they can be taken into account when whoever's
doing so writes up the proposal for that, and to draw attention to the key
axes of disagreement to help people to understand how I see the problems
at hand to inform their decision making for the final vote.

If, however, you still consider the governance proposal to be the worse risk,
you should absolutely vote against it - after all, my entire goal here was to
give the userbase a say in the future of the project, and if you use that say
to vote it down en masse then that genuinely still meets that goal.

Thank you for reading. I'm going to go grab a beer and miss the old riba.

--
Matt S Trout - Shadowcat Systems - Perl consulting with a commit bit and a clue

http://shadowcat.co.uk/blog/matt-s-trout/   http://twitter.com/shadowcat_mst/

Email me now on mst (at) shadowcat.co.uk and let's chat about how our CPAN
commercial support, training and consultancy packages could help your team.

_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The email I didn't want to write.

Peter Rabbitson-2
Matt, thank you for writing this email. It further highlights where we
differ, and will serve as a good trampoline for me to distill my point
further. There is a lot of stuff to unpack here, and given text is not
my forte I will take my time to respond in full some time this weekend
(along with my proposal).

I am going to only highlight a few of the inaccuracies below, as they
require further comment on Matt's part.

On 11/01/2016 11:18 PM, Matt S Trout wrote:
>
> ...
>
> This seems like a surprising description of ilmari, given he holds the
> first-come permissions for both DBIx::Class::Schema::Loader and SQL::Abstract

PAUSE disagrees:

rabbit@Ahasver:~$ curl -s
http://cpan.metacpan.org/modules/06perms.txt.gz | zgrep
'^SQL::Abstract,.*,f$'
SQL::Abstract,MSTROUT,f

> and conducted a huge and highly successful refactor of the former.

True, ilmari did work on S::L recently, but let's give credit where
credit is due:

rabbit@Ahasver:~/devel/schema_loader$ perl_git_stats lib t
As of 4f1bda9 GRAND_TOTAL stats => {
   blank_lines => 7320,
   code_lines => 21874,
   comment_lines => 1027,
   pod_lines => 2584,
   total_lines => 32805
}
[hidden email] stats => {
   blank_lines => 3652,
   code_lines => 11265,
   comment_lines => 587,
   pod_lines => 957,
   total_lines => 16461
}
[hidden email] stats => {
   blank_lines => 635,
   code_lines => 2634,
   comment_lines => 128,
   pod_lines => 564,
   total_lines => 3961
}
[hidden email] stats => {
   blank_lines => 1061,
   code_lines => 2435,
   comment_lines => 62,
   pod_lines => 424,
   total_lines => 3982
}

>
>...
>
> Meanwhile, we've now reached a point where seeing a ticket or patch sent in
> by ribasushi tends to result in people ignoring it for a few days because
> they need to work up the emotional stoicism required to deal with the chances
> of it being a useful patch/ticket that happens to come with a free polemic.

Citation needed. Please provide an example where I have been abusive or
even slightly unprofessional in a bugreport. Issue trackers are
generally always part of the public record, so it shouldn't be a problem
to back up what was said above.

>
> ...
>
> - who's actively attacked and/or alienated the owners of many of our downstream
>   dependencies, including the crucial SQL::Abstract

Even correcting for the error of who the actual SQLA owner is, here are
the stats of the top 6 contributors:

rabbit@Ahasver:~/devel/sqla$ perl_git_stats lib t
As of 18710f6 GRAND_TOTAL stats => {
   blank_lines => 2540,
   code_lines => 12460,
   comment_lines => 775,
   misc_lines => 2,
   pod_lines => 2219,
   total_lines => 17996
}
[hidden email] stats => {
   blank_lines => 494,
   code_lines => 3594,
   comment_lines => 259,
   pod_lines => 322,
   total_lines => 4669
}
[hidden email] stats => {
   blank_lines => 211,
   code_lines => 1087,
   comment_lines => 12,
   pod_lines => 106,
   total_lines => 1416
}
[hidden email] stats => {
   blank_lines => 97,
   code_lines => 925,
   comment_lines => 35,
   pod_lines => 45,
   total_lines => 1102
}
[hidden email] stats => {
   blank_lines => 290,
   code_lines => 553,
   comment_lines => 25,
   pod_lines => 414,
   total_lines => 1282
}
[hidden email] stats => {
   blank_lines => 410,
   code_lines => 548,
   comment_lines => 99,
   misc_lines => 2,
   pod_lines => 309,
   total_lines => 1368
}
[hidden email] stats => {
   blank_lines => 16,
   code_lines => 195,
   comment_lines => 13,
   pod_lines => 27,
   total_lines => 251
}

If we look at SQL::Abstract alone (which arguably should have been the
only thing in the dist, but I dropped the ball there), we still get:

rabbit@Ahasver:~/devel/sqla$ perl_git_stats lib/SQL/Abstract.pm
As of 18710f6 GRAND_TOTAL stats => {
   blank_lines => 1300,
   code_lines => 1889,
   comment_lines => 251,
   misc_lines => 1,
   pod_lines => 1890,
   total_lines => 5331
}
[hidden email] stats => {
   blank_lines => 161,
   code_lines => 536,
   comment_lines => 56,
   pod_lines => 254,
   total_lines => 1007
}
[hidden email] stats => {
   blank_lines => 321,
   code_lines => 332,
   comment_lines => 84,
   misc_lines => 1,
   pod_lines => 276,
   total_lines => 1014
}
[hidden email] stats => {
   blank_lines => 251,
   code_lines => 99,
   comment_lines => 11,
   pod_lines => 414,
   total_lines => 775
}
[hidden email] stats => {
   blank_lines => 20,
   code_lines => 72,
   comment_lines => 7,
   pod_lines => 18,
   total_lines => 117
}
[hidden email] stats => {
   blank_lines => 16,
   code_lines => 57,
   comment_lines => 10,
   pod_lines => 27,
   total_lines => 110
}

Matt, with all said above - can you please clarify:

> - who's actively attacked and/or alienated the owners of many of our downstream
>   dependencies, including the crucial SQL::Abstract

Cheers


P.S. All stats generated by the following script.It essentially
correlates deep-blame (ignoring whitespace changes and trying to detect
trans-file copies with default git settings), with the type of file region.

https://gist.github.com/ribasushi/600bcbc0c84f5825b1236fb02c57dda3#file-perl_git_stats-pl

_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The email I didn't want to write.

Peter Rabbitson-2
On 11/02/2016 11:50 AM, Peter Rabbitson wrote:
>
> P.S. All stats generated by the following script.It essentially
> correlates deep-blame (ignoring whitespace changes and trying to detect
> trans-file copies with default git settings), with the type of file region.
>
> https://gist.github.com/ribasushi/600bcbc0c84f5825b1236fb02c57dda3#file-perl_git_stats-pl
>

As excellent demonstration of why I should not be working given my
current sleep schedule: the summing of the totals in the original script
was wrong. As a result each 'As of XXXXXXX GRAND_TOTAL stats' in my
preceding email is incorrect. The rest is unchanged.

Fix pushed to gist, rerun the stats locally for a better picture.
https://gist.github.com/ribasushi/600bcbc0c84f5825b1236fb02c57dda3/revisions

_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The email I didn't want to write.

Christian Walde
In reply to this post by Peter Rabbitson-2
On Wed, 02 Nov 2016 11:50:24 +0100, Peter Rabbitson  
<[hidden email]> wrote:

> rabbit@Ahasver:~/devel/schema_loader$ perl_git_stats lib t
>
> rabbit@Ahasver:~/devel/sqla$ perl_git_stats lib t

I don't think mst was trying to talk away contributions of others, but  
saying that you've talked about a *current active maintainer*.

ilmari has been, respectively, for 2† and 4‡ years the only consistently  
active person on the mentioned dists, which remains true even in the face  
of his commit counts being lower than those of previous contributors.

†  
https://github.com/dbsrgits/sql-abstract/graphs/contributors?from=2014-10-03&to=2016-11-02&type=c

‡  
https://github.com/dbsrgits/dbix-class-schema-loader/graphs/contributors?from=2011-10-28&to=2016-11-02&type=c

(Double-click on the time graph to expand to all of it, or click and drag  
to inspect timeframe.)

--
With regards,
Christian Walde

_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The email I didn't want to write.

Matt S Trout-2
In reply to this post by Peter Rabbitson-2
On Wed, Nov 02, 2016 at 11:50:24AM +0100, Peter Rabbitson wrote:

> On 11/01/2016 11:18 PM, Matt S Trout wrote:
> >
> >...
> >
> >This seems like a surprising description of ilmari, given he holds the
> >first-come permissions for both DBIx::Class::Schema::Loader and SQL::Abstract
>
> PAUSE disagrees:
>
> rabbit@Ahasver:~$ curl -s
> http://cpan.metacpan.org/modules/06perms.txt.gz | zgrep
> '^SQL::Abstract,.*,f$'
> SQL::Abstract,MSTROUT,f

Ah, my mistake. Of course, given your treatment of and attitude towards
me, my point is if anything rather stronger in that case.
 
> >and conducted a huge and highly successful refactor of the former.
>
> True, ilmari did work on S::L recently, but let's give credit where
> credit is due:

I was talking about during his first stint as DBICSL primary maintainer.

And, of course, given the entire point of refactoring is to make it easier
to maintain and extend a codebase, the fact that a number of people
successfully did so afterwards should rather be expected if the refactoring
were highly successful.
 

> >
> >...
> >
> >Meanwhile, we've now reached a point where seeing a ticket or patch sent in
> >by ribasushi tends to result in people ignoring it for a few days because
> >they need to work up the emotional stoicism required to deal with the chances
> >of it being a useful patch/ticket that happens to come with a free polemic.
>
> Citation needed. Please provide an example where I have been abusive
> or even slightly unprofessional in a bugreport. Issue trackers are
> generally always part of the public record, so it shouldn't be a
> problem to back up what was said above.

I could go back and find somebody mentioning being made to feel like that
and to then cross-reference to the ticket, but that would require outing
them as having said so and given your general treatment of disagreement in
this thread I'm not convinced that's fair. People may choose to disregard
this assertion on my part as a result if they so wish.

But let me ask you a slightly different question, phrased relatively openly
to avoid prejudicing your answer - why do you no longer discuss issues on
perl5-porters?
 
> Matt, with all said above - can you please clarify:
>
> >- who's actively attacked and/or alienated the owners of many of our downstream
> >  dependencies, including the crucial SQL::Abstract

Well, y'know, I came here for a governance discussion and honestly I'm
feeling pretty attacked right now.

"rabid badger"
"elephant in the room"
"enthusiast"
unfounded accusations of abuse of IRC OPER rights, quietly retracted without
an apology for the error

And, of course, we're rather dependent on SQL::Translator too and castaway
bowed out of this discussion some time back to avoid being attacked further.

My apologies for the single factual innacuracy; please consider that this
conversation might go more constructively if you were to ask me what I
meant about questions rather than simply assert that I'm wrong.

--
Matt S Trout - Shadowcat Systems - Perl consulting with a commit bit and a clue

http://shadowcat.co.uk/blog/matt-s-trout/   http://twitter.com/shadowcat_mst/

Email me now on mst (at) shadowcat.co.uk and let's chat about how our CPAN
commercial support, training and consultancy packages could help your team.

_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The email I didn't want to write.

Matt S Trout-2
On Wed, Nov 02, 2016 at 11:33:12PM +0000, Matt S Trout wrote:

> > >...
> > >
> > >Meanwhile, we've now reached a point where seeing a ticket or patch sent in
> > >by ribasushi tends to result in people ignoring it for a few days because
> > >they need to work up the emotional stoicism required to deal with the chances
> > >of it being a useful patch/ticket that happens to come with a free polemic.
> >
> > Citation needed. Please provide an example where I have been abusive
> > or even slightly unprofessional in a bugreport. Issue trackers are
> > generally always part of the public record, so it shouldn't be a
> > problem to back up what was said above.
>
> I could go back and find somebody mentioning being made to feel like that
> and to then cross-reference to the ticket, but that would require outing
> them as having said so and given your general treatment of disagreement in
> this thread I'm not convinced that's fair. People may choose to disregard
> this assertion on my part as a result if they so wish.

Ah, here we go, one where the author has largely noped out of the perl
community after the resulting debacle:

https://github.com/perl5-utils/List-MoreUtils/pull/9

Impugning character rather than acknowledging technical disagreement:

"Still utterly missing (or deliberately ignoring) the actual problem..."

The various unncessary bolding that simply makes the tone more hostile.

Describing the thread as a "train-wreck of a conversation"

Resulting in (1) rehsack considering that "My impression is still that
most of the thread is more about mood than about hard facts." and (2)
rejecting further discussion with "Personal hint - stop the affronts and
search for a way to step forward in a cooperative manner."

Even if riba genuinely believes in his reply of:

"I urge you to stop making it personal. None of the recent discussions
are about you. They are fully and exclusively about grossly suboptimal
decisions. You just happened to be the one who carried these decisions out."

I feel like "it's not about you, it's just about all your decisions being
terrible" isn't really an effective way to move things forwards, especially
since it clearly resulted in the actual argument we were trying to make
being lost since rehsack's take-away was

"Trying to enforce something without technical reason in a technical world
is insane and the way how you do it is personal."

This is a classic example of a conversation where I was on the same side of
the technical argument as ribasushi, but his presence actively impeded being
able to have the technical argument in a constructive fashion.

Would this have gone better without riba's involvement? Maybe not - but it
seems moderately unlikely to me that it could've gone worse.

tl;dr: If people take your words personally, it's generally easier to change
your words than everybody else. I'm far from claiming that I'm perfect at
this, but I find it deeply unfortunate that ribasushi seems to believe that
there's nothing to be gained from even trying.

(you will also find that I'm in that thread as well, and also somewhat
annoyed, but never resorted to accusations of deliberately ignoring the
problem nor to throwing about random bits of bolding to add negative
emotional content that is almost invariably counterproductive to achieving
a constructive result)

--
Matt S Trout - Shadowcat Systems - Perl consulting with a commit bit and a clue

http://shadowcat.co.uk/blog/matt-s-trout/   http://twitter.com/shadowcat_mst/

Email me now on mst (at) shadowcat.co.uk and let's chat about how our CPAN
commercial support, training and consultancy packages could help your team.

_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The email I didn't want to write.

Christian Walde
In reply to this post by Peter Rabbitson-2
On Wed, 02 Nov 2016 11:50:24 +0100, Peter Rabbitson  
<[hidden email]> wrote:

> Citation needed. Please provide an example where I have been abusive or  
> even slightly unprofessional in a bugreport. Issue trackers are  
> generally always part of the public record, so it shouldn't be a problem  
> to back up what was said above.

I didn't want to bother, but rereading riba's arrogance and deceit  
combined with your past actions make me angry enough to bother.

He'll probably enjoy that i write this, but well, if he does, he's free to  
enjoy it while he can.

Meanwhile i think it's only fair that his userbase knows what his  
principles really *mean*.

The following did not have him act in an RT queue, but since his actions  
were in direct response and aimed towards affecting a ticket i filed, it  
is fair to bring up.

He did abuse me on IRC with the goal to get me to give up on the ticket.

He plainly said this to me and tried to justify it as being his duty as an  
engineer.

I did indeed give up on a ticket despite still considering it valid and in  
need of action due to him.

I had forgotten about it for months and not done anything about it at all.  
A reasonable person should think that would be enough for him to cross it  
off as done and leave things be.

However for some insane reason he thought it was appropiate to approach me  
again, a YEAR after i had originally filed the ticket, and tell me these  
things:

[...]
16-01-08@23:11:43 (ribasushi) I re-read the log in p5p several times in  
the past week
[...]
16-01-08@23:12:21 (ribasushi) if you agree for me to publish it unmodified  
(at most with slight reorder to compensate for IRC lag)
16-01-08@23:12:33 (ribasushi) I will publicly own to say in no uncertain  
terms that I went *EASY* on you
16-01-08@23:12:35 (ribasushi) and that I regret it
16-01-08@23:13:09 (Mithaldu) regret going easy, or having done it in the  
first place instead of looking at it on technical merits?
16-01-08@23:13:22 (ribasushi) I looked at the technical merits
16-01-08@23:13:25 (Mithaldu) also, publish whatever you liked
16-01-08@23:13:33 (ribasushi) and I didn't shut it down quickly enough nor  
forcefully enough
16-01-08@23:13:39 (Mithaldu) jesus fuck
16-01-08@23:13:43 (ribasushi) I wasn't using "radical candor" correctly
16-01-08@23:13:46 (Mithaldu) you are an abbhorrent piece of shit
16-01-08@23:13:53 (ribasushi) and this is something I do regret
[...]

He might possibly argue that this was him being professional, delivering a  
final kick to the liver to ensure it sticks.

However in no possible conceivable way does this deserve ANY respite from  
receiving the label "abusive".

I am also not the only person to be treated like that. He said the  
following about his treatment of another developer in various venues,  
including a github queue:

15-05-11@14:00:22 (ribasushi) at this point it is *my engineering duty* to  
drive him away from perl

Again, he probably thinks it is professional to do that, but trying to  
claim here that it is not abuse is a lie, given he has stated outright  
that he was abusing said dev with that particular goal.

--
With hate,
Christian Walde

_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The email I didn't want to write.

Alexander Hartmaier
Can everybody please stop bashing ribasushi and work on a solution to
get the DBIC development process going again?!

Peter is also 'only' a human being and if his interpersonal skills would
be higher his technical expertise might not be as good as it is because
no one can shine everywhere.

Thanks!


On 2016-11-03 18:34, Christian Walde wrote:

> On Wed, 02 Nov 2016 11:50:24 +0100, Peter Rabbitson
> <[hidden email]> wrote:
>
>> Citation needed. Please provide an example where I have been abusive
>> or even slightly unprofessional in a bugreport. Issue trackers are
>> generally always part of the public record, so it shouldn't be a
>> problem to back up what was said above.
>
> I didn't want to bother, but rereading riba's arrogance and deceit
> combined with your past actions make me angry enough to bother.
>
> He'll probably enjoy that i write this, but well, if he does, he's
> free to enjoy it while he can.
>
> Meanwhile i think it's only fair that his userbase knows what his
> principles really *mean*.
>
> The following did not have him act in an RT queue, but since his
> actions were in direct response and aimed towards affecting a ticket i
> filed, it is fair to bring up.
>
> He did abuse me on IRC with the goal to get me to give up on the ticket.
>
> He plainly said this to me and tried to justify it as being his duty
> as an engineer.
>
> I did indeed give up on a ticket despite still considering it valid
> and in need of action due to him.
>
> I had forgotten about it for months and not done anything about it at
> all. A reasonable person should think that would be enough for him to
> cross it off as done and leave things be.
>
> However for some insane reason he thought it was appropiate to
> approach me again, a YEAR after i had originally filed the ticket, and
> tell me these things:
>
> [...]
> 16-01-08@23:11:43 (ribasushi) I re-read the log in p5p several times
> in the past week
> [...]
> 16-01-08@23:12:21 (ribasushi) if you agree for me to publish it
> unmodified (at most with slight reorder to compensate for IRC lag)
> 16-01-08@23:12:33 (ribasushi) I will publicly own to say in no
> uncertain terms that I went *EASY* on you
> 16-01-08@23:12:35 (ribasushi) and that I regret it
> 16-01-08@23:13:09 (Mithaldu) regret going easy, or having done it in
> the first place instead of looking at it on technical merits?
> 16-01-08@23:13:22 (ribasushi) I looked at the technical merits
> 16-01-08@23:13:25 (Mithaldu) also, publish whatever you liked
> 16-01-08@23:13:33 (ribasushi) and I didn't shut it down quickly enough
> nor forcefully enough
> 16-01-08@23:13:39 (Mithaldu) jesus fuck
> 16-01-08@23:13:43 (ribasushi) I wasn't using "radical candor" correctly
> 16-01-08@23:13:46 (Mithaldu) you are an abbhorrent piece of shit
> 16-01-08@23:13:53 (ribasushi) and this is something I do regret
> [...]
>
> He might possibly argue that this was him being professional,
> delivering a final kick to the liver to ensure it sticks.
>
> However in no possible conceivable way does this deserve ANY respite
> from receiving the label "abusive".
>
> I am also not the only person to be treated like that. He said the
> following about his treatment of another developer in various venues,
> including a github queue:
>
> 15-05-11@14:00:22 (ribasushi) at this point it is *my engineering
> duty* to drive him away from perl
>
> Again, he probably thinks it is professional to do that, but trying to
> claim here that it is not abuse is a lie, given he has stated outright
> that he was abusing said dev with that particular goal.
>



*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
Notice: This e-mail contains information that is confidential and may be privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*

_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The email I didn't want to write.

Charlie Garrison
On 7 Nov 2016, at 20:24, Hartmaier Alexander wrote:

> Peter is also 'only' a human being and if his interpersonal skills
> would
> be higher his technical expertise might not be as good as it is
> because
> no one can shine everywhere.

It seems to me that people bashing ribasushi should be working on their
own interpersonal skills. I’ve yet to hear any arguments or see any
evidence which voids Peter’s technical expertise.

When I come against who I believe to be a very stubborn person who
won’t listen, I take the opportunity to improve my communication and
reasoning skills (assuming something important, otherwise just walk
away). Making the ‘the problem’ someone else just makes the
situation harder for me; it’s much easier to fix myself than fix
someone else.

cng

--

    Charlie Garrison  <[hidden email]>
    github.com/cngarrison   metacpan.org/author/CNG

_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The email I didn't want to write.

Matt S Trout-2
On Tue, Nov 08, 2016 at 07:32:02AM +1100, Charlie Garrison wrote:

> On 7 Nov 2016, at 20:24, Hartmaier Alexander wrote:
>
> >Peter is also 'only' a human being and if his interpersonal skills
> >would
> >be higher his technical expertise might not be as good as it is
> >because
> >no one can shine everywhere.
>
> It seems to me that people bashing ribasushi should be working on
> their own interpersonal skills. I’ve yet to hear any arguments or
> see any evidence which voids Peter’s technical expertise.

DBIx::Class is dependent on, and a dependency of, many components of
the overall CPAN ecosystem.

I consider riba's increasing unwillingness to apply his technical expertise
constructively to the ecosystem, but instead to make decisions like

  (ribasushi) at this point it is *my engineering duty* to drive him
              away from perl

to be a material risk to the future of the project; many of us have been
working around him for over a year now to avoid conflict on the expectation
that he was going to be retiring anyway, and if he remains and continues
to behave the same way it's going to be very difficult for DBIx::Class to
get the voice it deserves in discussions around related modules.

> When I come against who I believe to be a very stubborn person who
> won’t listen, I take the opportunity to improve my communication and
> reasoning skills (assuming something important, otherwise just walk
> away). Making the ‘the problem’ someone else just makes the
> situation harder for me; it’s much easier to fix myself than fix
> someone else.

That's an attitude that you and I generally share; what I find unfortunate
is deciding to break somebody else instead of convincing them to do the
right thing.

--
Matt S Trout - Shadowcat Systems - Perl consulting with a commit bit and a clue

http://shadowcat.co.uk/blog/matt-s-trout/   http://twitter.com/shadowcat_mst/

Email me now on mst (at) shadowcat.co.uk and let's chat about how our CPAN
commercial support, training and consultancy packages could help your team.

_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@...
Loading...