<div dir="ltr">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).<br><br>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 <a href="http://www.nntp.perl.org/group/perl.modules/2016/10/msg96180.html">http://www.nntp.perl.org/group/perl.modules/2016/10/msg96180.html</a> 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:<div><br></div><div>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.</div><div><br></div><div>---</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>---</div><div><br></div><div>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.</div><div><br></div><div>I don't envy you David, this is a tough matter. I hope that an equitable solution can be reached.</div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Oct 4, 2016 at 11:28 AM Matt S Trout <<a href="mailto:mst@shadowcat.co.uk">mst@shadowcat.co.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, Oct 04, 2016 at 11:21:36AM +0100, Pedro Melo wrote:<br class="gmail_msg">
> Hi,<br class="gmail_msg">
><br class="gmail_msg">
> On 4/10/16 1:15 AM, "Ashley Pond V" <apv at <a href="http://sedition.com" rel="noreferrer" class="gmail_msg" target="_blank">sedition.com</a>> wrote:<br class="gmail_msg">
> >My view: MST must be respected but I personally defer to RIBASUSHI and<br class="gmail_msg">
> >his judgement. I say, what he says, goes. He has earned the benefit of<br class="gmail_msg">
> >the doubt. At least until it can be clearly demonstrated the approach<br class="gmail_msg">
> >is harming the code base should that ever become the case.<br class="gmail_msg">
><br class="gmail_msg">
> +1, I could not have written this better.<br class="gmail_msg">
<br class="gmail_msg">
Given ribasushi's plan is "end all feature development because nobody else<br class="gmail_msg">
can be trusted to add features without potentially introducing bugs", I'm<br class="gmail_msg">
not sure how one could 'demonstrate harm' - freezing it and never adding<br class="gmail_msg">
any features again is unlikely to *harm* the code base, merely kill the<br class="gmail_msg">
project.<br class="gmail_msg">
<br class="gmail_msg">
I mean, he's absolutely right that anybody else will, at this point,<br class="gmail_msg">
be more likely to introduce bugs in the process of continuing development,<br class="gmail_msg">
but if you read castaway's and ilmari's comments here:<br class="gmail_msg">
<br class="gmail_msg">
<a href="http://www.nntp.perl.org/group/perl.modules/2016/10/msg96192.html" rel="noreferrer" class="gmail_msg" target="_blank">http://www.nntp.perl.org/group/perl.modules/2016/10/msg96192.html</a><br class="gmail_msg">
<a href="http://www.nntp.perl.org/group/perl.modules/2016/10/msg96191.html" rel="noreferrer" class="gmail_msg" target="_blank">http://www.nntp.perl.org/group/perl.modules/2016/10/msg96191.html</a><br class="gmail_msg">
<br class="gmail_msg">
that's at least partially because we've been effectively locked out of<br class="gmail_msg">
contributing to the codebase for a couple years now, and all development<br class="gmail_msg">
has been basically done without the discussion that would help us understand<br class="gmail_msg">
the implementation as well as the goals.<br class="gmail_msg">
<br class="gmail_msg">
I mean, if you genuinely believe ribasushi's right, and nobody else in the<br class="gmail_msg">
world is competent to add features to DBIx::Class ever again, then fair<br class="gmail_msg">
enough, let's start planning the funeral. But I can't see how that's the<br class="gmail_msg">
best possible outcome here for the userbase as a whole.<br class="gmail_msg">
<br class="gmail_msg">
--<br class="gmail_msg">
Matt S Trout - Shadowcat Systems - Perl consulting with a commit bit and a clue<br class="gmail_msg">
<br class="gmail_msg">
<a href="http://shadowcat.co.uk/blog/matt-s-trout/" rel="noreferrer" class="gmail_msg" target="_blank">http://shadowcat.co.uk/blog/matt-s-trout/</a> <a href="http://twitter.com/shadowcat_mst/" rel="noreferrer" class="gmail_msg" target="_blank">http://twitter.com/shadowcat_mst/</a><br class="gmail_msg">
<br class="gmail_msg">
Email me now on mst (at) <a href="http://shadowcat.co.uk" rel="noreferrer" class="gmail_msg" target="_blank">shadowcat.co.uk</a> and let's chat about how our CPAN<br class="gmail_msg">
commercial support, training and consultancy packages could help your team.<br class="gmail_msg">
<br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
List: <a href="http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class" rel="noreferrer" class="gmail_msg" target="_blank">http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class</a><br class="gmail_msg">
IRC: <a href="http://irc.perl.org#dbix-class" rel="noreferrer" class="gmail_msg" target="_blank">irc.perl.org#dbix-class</a><br class="gmail_msg">
SVN: <a href="http://dev.catalyst.perl.org/repos/bast/DBIx-Class/" rel="noreferrer" class="gmail_msg" target="_blank">http://dev.catalyst.perl.org/repos/bast/DBIx-Class/</a><br class="gmail_msg">
Searchable Archive: <a href="http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk" rel="noreferrer" class="gmail_msg" target="_blank">http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk</a><br class="gmail_msg">
</blockquote></div>