develooper Front page | perl.modules | Postings from October 2016

Re: Message from PAUSE Admins to DBIx::Class maintainers [resend]

Thread Previous | Thread Next
Peter Rabbitson
October 1, 2016 08:06
Re: Message from PAUSE Admins to DBIx::Class maintainers [resend]
Message ID:
On 09/22/2016 01:51 AM, David Golden wrote:
> *Our position:*
> (1) Given the importance of DBIC to the broader Perl community (i.e. 
> way "upriver <>"), we’d 
> like to see a more open discussion between existing maintainers about 
> what happens next in terms of DBIC leadership and control of primary 
> permissions.
> (2) The best outcome from our perspective would be for a successor to 
> be decided by consensus of existing maintainers.
> (3) Given a dispute among maintainers, the only outcome that is 
> absolutely unacceptable to PAUSE admins would be a unilateral 
> permissions transfer decision.
> (4) We really hope the DBIC maintainers and/or community can resolve 
> this internally.

On 09/22/2016 01:53 AM, David Golden wrote:
> For the good of the community, we believe the situation is best 
> resolved through discussion rather than fiat. We believe the DBIC 
> maintainers, authors and/or the broader DBIC community are the best 
> informed to decide the future direction of DBIC.

Apologies for the late reply, had trouble finding time to deal with this.

The entire thread[1][2][3] got skewed really fast, with a number of 
assumptions laid out as facts implicitly recognized by all sides (or 
even by anything resembling a majority). This is decidedly not the case, 
thus is it really hard for me to answer the raised questions directly in 
any way approaching a satisfactory manner.

For instance the content of the "our position" heading is entirely 
centered around the premise that a dispute exists between me (the 
1st-come) and a wronged community of people spearheaded by a team of 
dissatisfied individuals ("maintainers"). While this indeed may be the 
case - this is the first time I ever hear about it, and what's worse - 
from a 3rd party ("we"/pause admins).

To cut down on the cross-chatter I will summarize the chain of 
verifiable events, and then briefly outline my plans, finishing with a 
question to the PAUSE admins at the end. It took me a considerable 
amount of time to put this together, I hope you will respect this effort 
by crafting a similarly thought out response.

=== Timeline

  1) 2006-03-03: I make my first contribution ( a test enhancement ) to 
the project [4]
  2) 2008-04-20: I make my first own commit to the project repository [5]
  3) 2009-02-11: First indexed release by myself [6]
  4) 2010-06-10: mst reassigns 1st come of the DBIC distribution to myself
  5) End 2010 ~ Mid 2012: Seeing clear signs of trouble I go above and 
beyond trying to institute some sort of formal structure to stem the 
tide of "wfm" patches landing with no regard for the (now extremely 
large) user-base
  6) ~ May 2012: I fail on all counts to organize anything resembling a 
process and quit in exasperation after a particularly bad breach of 
quality ( during which the rest of the folks involved abdicate any 
responsibility )
  7) May 2012 ~ Nov 2012: The project is adrift, with only minor fixups 
- lib/ receives a total of 30 commits[7] ( some of which end up being 
reverted later )
  8) 2012-07-24: I am forced to come back and perform rather complex 
~2900loc surgery[8] to back out unfinished work that was shipped despite 
my objections, after several weeks of bugreports go warnocked
  9) 2012-08-24: A new version of DBIC ships after almost 2 months of an 
unusable indexed release
10) 2012-11-03: Seeing how development is effectively frozen I guilt 
myself into coming back, to at least finish the optimization work thrown 
away earlier
11) Nov 2012 ~ July 2012: I gradually get re-involved in the project in 
full, which ends up un-freezing things, leading to a noticeable uptick 
of sub-par work from problematic devs
12) 2013-07-12: Approaching my breaking point once again, and already 
knowing how this movie ends I write a plea to the user-base to determine 
once and for all what does it actually want from the library[9]. I 
receive an overwhelming display of support[10], with multiple high 
ranking names asserting my right to single-handedly steer the project. 
As a result DBIC transitions (to my great *dis*pleasure) to a BDFL-based 
one: everyone and everything is deferred to me as a sole holder of 
13) 2013-11-28: Last ever commit by mst fit for inclusion into the 
master branch [11]
14) 2013-11-29: Last ever commit by mst to any of the known to me DBIC 
repos [12]
15) Mid 2013 ~ Mid 2015: A number of less-than-awesome "new wave" 
maintainers take control of critical pieces of the wider dependency 
chain. With the quality of a large section of the CPAN offerings in 
free-fall[11], continuous work on the DBIC project becomes more and more 
pointless (as the project can not exist in a vacuum).
16) Oct 2015 ~ Dec 2015: Realizing that nothing short of "beyond 
full-time" involvement in the DBIC project and the wider CPAN can yield 
any long-term value, I make an attempt to secure funding for just this 
kind of effort [13]
17) 2015-12-06: Above attempt fails [14]. I specifically write down (and 
say [15]) "I will transfer myFIRSTCOME permissions 
<>to perl developers of my 
18) 2015-12-07: mst approaches me on pm, with the ensuing (short, and 
from what I can tell controversy-free) conversation taking place: [16]
19) 2015-12-25: Looking over the options for the project, and realizing 
there is nothing even close to a qualified successor I commit to carry 
out some more work before placing the project in maintenance-mode. I 
detail the steps of what I am planning to do in [17]
20) Jan 2016 ~ Sep 2016: I start working down the self-imposed hitlist, 
while looking for suitable employment. The search takes way more than 
expected, and so does the implementation of the solutions to the 
hitlist. A truly surreal (in hindsight) chain of events makes it 
possible and reasonable for me to essentially dedicate nearly 9 extra 
months to the project, albeit on goals markedly different from those 
within the failed campaign plan. A part of the associated git reflog can 
be seen in [18]. The progress has been steadily documented in 
near-monthly updates at the official mailing list [19]

=== Present day

There have been several unscheduled releases since, some to fix failing 
tests due to a shifting CPAN landscape [20][21] and one intermediate 
release as recently as 3 months ago incorporating some of the work done 
so far [22].

I continue to be involved in end-user support, both on the ML and on IRC 
(though I reduced my engagement on the #dbix-class channel, and instead 
try to help folks in a less polarized forum)

The commit-activity distribution since my involvement in the project is 
the following:

~/devel/dbic$ git shortlog -sn dc7d89911 ^96e7f9ec | head -n 30
   3101    Peter Rabbitson
    616    Rafael Kitover
    155    Arthur Axel "fREW" Schmidt
    102    John Napiorkowski
     78    Jess Robinson
     76    Rob Kinyon
     75    Norbert Buchmuller
     70    Dagfinn Ilmari Mannsåker
     67    Alexander Hartmaier
     66    Matt S Trout
     58    Justin Hunter
     57    Robert Buels
     41    Nigel Metheringham
     35    Gordon Irving
     32    Luke Saunders
     31    Johannes Plunien
     27    Guillermo Roditi
     27    Robert Bohne
     25    Amiri Barksdale
     21    Ash Berlin
     21    Moritz Onken
     18    Karen Etheridge
     16    Brendan Byrd
     16    Jason M. Mills
     16    Wallace Reis
     14    Daniel Ruoso
     13    Eden Cardim
     12    Ton Voon
     10    Florian Ragwitz
      8    Dan Dascalescu

Out of the top 4 (3-digit numbers of committers):

- Rafael Kitover left the project 3 years ago
- Frew Schmidt is a close friend who has neither the time nor the 
desire[23] to take over the project
- John Napiorkowski already has his hands full with Catalyst, and to the 
best of my knowledge is distancing himself from that as well

In more recent times (past ~year) the only other person on the above 
list who contributed code is Dagfinn Ilmari Mannsåker. Some of his work 
has already made it into mailnline, while other has been delayed ( none 
of it rejected ), due to a combination of review tuits and/or tuits 
necessary to fix sub-par sections of the submissions.

=== Future plans

As of today (Oct 1st) I am still enjoying some available time, due to an 
unexpected delay in the commencement of my employment (now hopefully Oct 

I am planning to use this available time well, just as I have 
demonstrably done so far (last substantial merge tool place just 
yesterday). The checklist introduced in [17] is nearly fully burned down 
(albeit at a cost of a bit more than 50 hours).

I am still planning to wrap up the remaining pieces, including some 
unannounced initiatives to get the project into the best shape possible 
to survive its leaderlessness.

I am still planning to remove all co-maint perms and handover the 
first-come to a yet-undisclosed person. Given no clear line of 
succession, and the incredibly high stakes wrt compatibility, the only 
responsible thing to do is to select a single spot of responsibility and 
provide all possible support and infrastructure for a proper 
project-freeze. I must stress that I am removing myself from the 
equation as well, so if the new powers that be decide to restore 
everything - I will have no tools to prevent them from doing so.

The selected person will not be announced until after the fact, in order 
to insulate him from having to deal with mst, before any permission 
transfer has taken place (or before my own work has even completed). In 
order to ease tensions I *will* share that he is a well known community 
member and was an invitee to at least one Perl5 QA Hackathon.

=== Questions to "maintainers" (addressed on CC, both as per PAUSE and 
as per a list of who mst considers "maintainers", based on an email from 

If any of you, truly has any complaints with my past performance, my 
current work, or my near-future plans: I invite you to lodge a complaint 
on the project's mailing list. I am not making the same announcement on 
the mailing lsit itself, because up to this day there have been no 
actual credible complaints by anyone (that I am aware of). If any of the 
readers feel this is dishonest - feel free to make such a post on the ML 

In any case: if the next weeks reveal that there indeed is strong 
pushback by actual developers/users against any of my choices (i.e. 
there is a strong reversal of opinion compared to [10]) I pledge not to 
ignore them but act to address them.

=== Response to issue raised by mst

And coming to the "elephant in the room": I want to state in the most 
unambiguous terms possible that I do not recognize Matt S Trout as a 
spokesperson for any development or user community related to DBIC or 
for the Perl5-space at large for that matter. While his 
groundbreaking-style contributions had an undisputed positive impact on 
the language as a whole, his brazen disrespect of end-users and an 
abhorrent communication style had an equally significant negative impact 
on nearly all forums he frequents.

As such, quite literally "for the good of the community", I irredeemably 
classify any and all complaints and concerns raised by mst as void of 
any substance. Therefore none of his grievances are destined to receive 
an answer.

In other words - I will not be engaging in any conversation with Matt 
Trout in any shape way or form (direct or mediated). If the PAUSE admins 
feel his complaints do have merit - the only way to address them would 
be by fiat.

=== Question to the PAUSE admins

To put it in the simplest terms: what is the conversation we are having 
here? We are talking about one of the (if not *the*) most openly and 
responsibly led projects on CPAN. Moreover I have not deviated from a 
single action-item as outlined at the end of [14] and in [17] - 9(!) 
months ago. The only failing is that the entire process took 
significantly more time than I originally anticipated. Please explain 

Peter Rabbitson

[7] dbic_checkout$ git log --format='%h %aN %cD %s' --reverse ^e6ff36589 
0d8817b^ lib

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