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 <http://neilb.org/2015/04/20/river-of-cpan.html>"), 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 responsibility. 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 <http://perladvent.org/2013/2013-12-08.html>to perl developers of my choosing" 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 17th)

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 2016-09-09)

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 yourself.

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 yourselves.



Regards
Peter Rabbitson

 [1] http://www.nntp.perl.org/group/perl.modules/2016/09/msg96115.html
 [2] http://www.nntp.perl.org/group/perl.modules/2016/09/msg96139.html
 [3] http://www.nntp.perl.org/group/perl.modules/2016/09/msg96140.html
 [4] https://github.com/dbsrgits/dbix-class/commit/9fcda149
 [5] https://github.com/dbsrgits/dbix-class/commit/96e7f9ec
 [6] https://metacpan.org/release/RIBASUSHI/DBIx-Class-0.08011
[7] dbic_checkout$ git log --format='%h %aN %cD %s' --reverse ^e6ff36589 0d8817b^ lib
 [8] https://github.com/dbsrgits/dbix-class/commit/c9733800
[9] http://blogs.perl.org/users/peter_rabbitson/2013/07/crowdsourcing-self-confidence.html [10] http://blogs.perl.org/users/peter_rabbitson/2013/07/crowdsourcing-self-confidence.html#comments
[11] https://github.com/dbsrgits/dbix-class/commit/6fc6d60c
[12] https://github.com/dbsrgits/dbix-class/commit/b16a3603
[13] https://www.reddit.com/r/perl/comments/3n4c85/i_am_a_perl5_developer_asking_25_companies_to/ [14] https://www.reddit.com/r/perl/comments/3vnsiw/suspending_efforts_on_my_riba2016_crowdfunding/
[15] https://youtu.be/U7KOJCUITVs?t=318
[16] https://gist.github.com/ribasushi/f2502a29f5e2c7c48e03f7bd34e7ddd2
[17] http://blogs.perl.org/users/peter_rabbitson/2015/12/riba2016-ends.html
[18] https://gist.github.com/ribasushi/6ea33c921927c7571f02e5c8b09688ef
[19] http://dbix-class.35028.n2.nabble.com/Re-Traffic-pattern-changes-ahead-td7578918.html
[20] https://metacpan.org/release/RIBASUSHI/DBIx-Class-0.082821#whatsnew
[21] https://metacpan.org/release/RIBASUSHI/DBIx-Class-0.08271#whatsnew
[22] https://metacpan.org/release/RIBASUSHI/DBIx-Class-0.082840#whatsnew
[23] http://blogs.perl.org/users/peter_rabbitson/2013/07/crowdsourcing-self-confidence.html#comment-1129819

Reply via email to