A discussion of DBIx-Class governance and future development

Acting in my capacity as an administrator for PAUSE, I've been mediating a dispute over the future disposition of primary permissions for the DBIx::Class namespace on CPAN. I recently posted a message to the mailing list for DBIx::Class titled "IMPORTANT: A discussion of DBIC governance and future development".

I am reprinting it in full below in the hope that doing so will help this message reach DBIx::Class users who are not on the mailing list. I encourage such users to read the message and join the mailing list to participated in the conversation and express their interests.

Subject: IMPORTANT: A discussion of DBIC governance and future development

Hello, DBIC community.

I apologize in advance for the length of this email, but I urge everyone that uses DBIC to read it fully as it relates to the future of this important module.

For those who don't know me, I'm DAGOLDEN on CPAN and I've joined this list in my capacity as a PAUSE [1] administrator.

For those on the list who aren't familiar with CPAN administration, PAUSE is the service that authors use to upload modules to CPAN. Among other functions, it generates the index that maps modules names to downloadable tarballs – e.g. "DBIx::Class" to "RIBASUSHI/DBIx-Class-0.082840.tar.gz" on a CPAN mirror.

PAUSE also maintains a permissions model [2] for each module namespace with two levels: "primary maintainer" (also called "first come") and "co-maintainer" (aka "co-maint"). Primary maintainers can grant and revoke co-maint permissions. Both levels can upload tarballs to PAUSE, triggering an update to the index.

Over the past several weeks, I've been the PAUSE administrator selected to mediate a dispute over future disposition of primary permissions for the DBIx::Class namespace.

The dispute was triggered by Peter Rabbitson's "Traffic pattern changes ahead" [3] email to this list on September 6, in which he said:

I have also firmly selected who will be getting the DBIx::Class
namespace first-come, the transfer of which will also happen
somewhere around the end of September.

Because the identity of the new primary maintainer was neither disclosed nor discussed with Matt Trout (the founder of the DBIC project, current co-maintainer and also PAUSE administrator) or other co-maintainers, several private conversations between ensued between Matt, Peter and others about this declaration.

On September 15, Peter notified PAUSE administrators via the modules@perl.org mailing list of an "Upcoming PAUSE permissions dispute" [4]. Separately, Matt notified PAUSE administrators privately with his own concerns about a possible dispute (his email was later disclosed and I'll link to it later).

On September 21, I privately emailed all DBIC maintainers (CPAN authors ABRAXXA, ARODLAND, FREW, ILMARI, JROBINSON, MSTROUT, and RIBASUSHI) on behalf of PAUSE administrators with our collective view of how this dispute would be best resolved. Peter asked that any discussion be public, so I reposted it to the modules@perl.org mailing list as "Message from PAUSE Admins to DBIx::Class maintainers [resend]" [5]

I urge everyone to read that thread in full as well. For reference, it includes a copy [6] of Matt's previously private email to PAUSE administrators.

Importantly, the thread summarizes PAUSE administrators' position on the dispute, which I repost verbatim here:

  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.

In the ensuing discussion, Peter disclosed additional details about his plans for the future of DBIC in the "Future plans" section of this email [7]:

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.

In another email [8], Peter suggested raising these issues explicitly on the DBIC mailing list:

As suggested in an earlier email: the PAUSE admins (as the only
legitimate concerned party at this point) would likely benefit having
this question asked in a wider forum ( the DBIC mailing list and/or
other channels ). Essentially someone has to trigger a "vote of no
confidence", otherwise this entire exchange is just a time consuming farce.

On behalf of the PAUSE administrators, we would therefore like to invite Peter to describe in more detail his plans for a "project freeze" and the role he envisions for a successor maintainer. We invite Matt, other co-maintainers, and the DBIC community at large to add their thoughts about the specifics of the plan or about the situation in general.

Given public and private discussions to date, we believe the DBIC community should consider questions such as:

  • How should the future governance of the DBIC project be decided?
  • Who should or shouldn't be involved in future governance?
  • Should the project be "frozen" or should development continue?
  • If "frozen", what specifically would a "freeze" entail? Would there be exceptions?
  • If not "frozen", what principles should govern development? (Cathedral vs Bazaar [9] and/or New Jersey Style vs MIT Style [10])

We believe these discussions, if had openly, honestly and constructively, will lead to the best resolution of this dispute for the DBIC community.

Thank you for reading this far, and I look forward to reading the community's views on these matters.

Sincerely,
David Golden, PAUSE Administrator

[1] http://pause.perl.org/
[2] http://perladvent.org/2013/2013-12-08.html
[3] http://lists.scsys.co.uk/pipermail/dbix-class/2016-September/012187.html
[4] http://www.nntp.perl.org/group/perl.modules/2016/09/msg96115.html
[5] http://www.nntp.perl.org/group/perl.modules/2016/09/msg96139.html
[6] http://www.nntp.perl.org/group/perl.modules/2016/10/msg96178.html
[7] http://www.nntp.perl.org/group/perl.modules/2016/10/msg96174.html
[8] http://www.nntp.perl.org/group/perl.modules/2016/10/msg96182.html
[9] https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar
[10] https://en.wikipedia.org/wiki/Worse_is_better

This entry was posted in perl programming and tagged , , , . Bookmark the permalink. Both comments and trackbacks are currently closed.

© 2009-2017 David Golden All Rights Reserved