[Dbix-class] IMPORTANT: A discussion of DBIC governance and future development

Joel Berger joel.a.berger at gmail.com
Tue Oct 4 18:34:31 GMT 2016


I'm only an occasional user of DBIx::Class. I don't use it for work. I do
use it in my CMS Galileo (on CPAN) so I have some small standing I think. I
also am interested in the governance situation generally as some of it may
directly apply to another situation I'm in (more later).

First and foremost, I want to comment from the perspective of the outside
user. I want to reiterate (as I think this thread has already established)
that unlike what is asserted in
http://www.nntp.perl.org/group/perl.modules/2016/10/msg96180.html the lack
of people directly reaching out to ribasushi in regards to the handover of
DBIC should not be construed as lack of concern on the part of the
userbase. The problem as ever is the balance of feeling you have the
standing to respond and feeling you have something to contribute. I imagine
that there must be others who have had the thought "this does concern me,
but I don't know what to say about it, it is certainly a hard question", as
I have. In fact I'm not sure I have a whole lot more to say about this
particular situation than that, other than the following:

I really don't think that any plan to transfer first-come to another person
in secret is a great idea. Ribasushi has made it very clear the high
position DBIC holds within the pantheon of CPAN distributions. I doubt Riba
intends to pass it off to a malicious person, but in a worst case scenario,
if that did happen, the handoff itself is essentially a security
vulnerability. That is of course an alarmist response and I don't truly
believe that to be the case. The tenor of this discussion DOES brook some
concern though and I don't think outsiders looking in would be wrong to pin
their dependencies at this very moment. We all know that most CPAN users
don't (and indeed probably don't know how to) pin their dependencies, so it
is always in the best interest of these "gems of CPAN" to hand over
maintainership cleanly and openly. Again, I don't really have standing to
vote in such a cause but please keep these kind of concerns in mind while
this discussion continues.

---

On a slightly different note (as indicated before) there is a broader
governance question, namely the one that caused mst to hand off first-come
to Ribasushi in the first place. When it becomes expedient for a project
founder to hand over maintainership to another person, the only mechanism
to do it is to hand over first-come which essentially hands over all the
rights to the distribution. This is partially the root cause of this
dispute. I'm currently in a similar position wherein I would like to hand
over day-to-day administration of Alien::Base to its de-facto maintainer
Plicease. I haven't and will not do so because I still have strong opinions
about Alien::Base even if I'm not doing most of the work of its
development; Plicease is much more capable than I am in this area anyway.

That said I would like to see another level introduced into the PAUSE
permissions system. For lack of a better name I would call it maintainer.
Other people could hash out the specifics but generally it would be a role
which has the permissions of the current first-come but yet be subject to
the actual first-come (founder). I think had this level been available to
mst, there would not now be any discussion about who has the final say, the
project founder or the current first-come and major contributor. Further
discussion of this matter should probably be a different thread however.

---

Finally, I would like to offer my one and only personal opinion on the
matter at hand. Seeing the fact that DBIC was handed over to Ribasushi in
an administrative capacity only, specifically with the assertion that mst
wanted to retain rights to it is quite a twist to this story. Ribasushi has
taken very good care of it to be sure, but to now turn around and assert
that because of term of maintenance and number of commits/lines of code the
code is now his own and the previous arrangement is void is troubling.
Where is that line? Should mst have been informed when that line was
crossed and asked if he wanted it back? Again, before I knew of the terms
of the original handover I was inclined to side with Ribasushi as
first-come holder. Now with the new information, I'm very torn. I know I
would feel slighted if I had made a similar deal with someone to care for a
project I had founded. Given the lack of administrative option available to
mst, a handover with acknowledgement of retainer of rights was the only
option. Again, another level of PAUSE perms might have averted all of this.
In my perfect resolution of this, Ribasushi would live up to the original
bargain.

I don't envy you David, this is a tough matter. I hope that an equitable
solution can be reached.

On Tue, Oct 4, 2016 at 11:28 AM Matt S Trout <mst at shadowcat.co.uk> wrote:

> On Tue, Oct 04, 2016 at 11:21:36AM +0100, Pedro Melo wrote:
> > Hi,
> >
> > On 4/10/16 1:15 AM, "Ashley Pond V" <apv at sedition.com> wrote:
> > >My view: MST must be respected but I personally defer to RIBASUSHI and
> > >his judgement. I say, what he says, goes. He has earned the benefit of
> > >the doubt. At least until it can be clearly demonstrated the approach
> > >is harming the code base should that ever become the case.
> >
> > +1, I could not have written this better.
>
> Given ribasushi's plan is "end all feature development because nobody else
> can be trusted to add features without potentially introducing bugs", I'm
> not sure how one could 'demonstrate harm' - freezing it and never adding
> any features again is unlikely to *harm* the code base, merely kill the
> project.
>
> I mean, he's absolutely right that anybody else will, at this point,
> be more likely to introduce bugs in the process of continuing development,
> but if you read castaway's and ilmari's comments here:
>
> http://www.nntp.perl.org/group/perl.modules/2016/10/msg96192.html
> http://www.nntp.perl.org/group/perl.modules/2016/10/msg96191.html
>
> that's at least partially because we've been effectively locked out of
> contributing to the codebase for a couple years now, and all development
> has been basically done without the discussion that would help us
> understand
> the implementation as well as the goals.
>
> I mean, if you genuinely believe ribasushi's right, and nobody else in the
> world is competent to add features to DBIx::Class ever again, then fair
> enough, let's start planning the funeral. But I can't see how that's the
> best possible outcome here for the userbase as a whole.
>
> --
> 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@lists.scsys.co.uk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scsys.co.uk/pipermail/dbix-class/attachments/20161004/1d3dc838/attachment-0001.htm>


More information about the DBIx-Class mailing list