<div dir="ltr">+1 for the fork </div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 31, 2016 at 6:24 PM, Darren Duncan <span dir="ltr"><<a href="mailto:darren@darrenduncan.net" target="_blank">darren@darrenduncan.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">My current thought is that a fork may be the best solution in the short term, with the following clarifications or amendments.<br>
<br>
1. Peter Rabbitson would have the exclusive PAUSE permissions to the DBIx::Class namespace and would continue to perform releases of his work on it as he wanted to do. He would also designate others to have those permissions as he chooses, and he would choose his own successor. This namespace would emphasize stability and/or Peter's objectives.<br>
<br>
2. Matt would create a fork using his proposed governance model to further evolve along those lines. The fork would emphasize their objectives, and would probably include most major work not done by Peter.<br>
<br>
3. I hope that Peter would still be open to pull requests but he should publish some documentation giving an outline of what qualities he would look for in patches from others so they would more likely be accepted. My assumption however, is that in a fork scenario most pull requests would just go to the fork, and pull requests on the original would be limited to small things like security or bug fixes.<br>
<br>
4. In the future, if Peter decides to leave again and/or there is no successor, the DBIx::Class namespace can be treated according to abandoned module protocol, where Peter has no outstanding interest, unlike now.<br>
<br>
5. Ideally DBIC, both versions, would be as duck-typed as possible with its API, so that dependent modules or applications could switch between them more easily, without having to do a lot of tests on the names of classes.<br>
<br>
This all being said, I am ALSO fine with Matt's governance proposal being used with the DBIx::Class namespace, though given that Peter's further committer involvement is basically mutually exclusive with this, I consider it less ideal for that reason.<br>
<br>
I also recognize that DBIC has its own network of extensions, and I don't know if they are duck-typed or not, eg would they themselves need substantial or any changes to work in a forked ecosystem, or if one could use them with both different-names DBIC versions unchanged.<br>
<br>
I see that as a main complicating factor. Applications, not so much; if they want stability, Peter's version should serve them; if they want substantial changes or new features that more likely may be in the fork, they would have to be changed anyway.<span class="HOEnZb"><font color="#888888"><br>
<br>
-- Darren Duncan</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
______________________________<wbr>_________________<br>
List: <a href="http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class" rel="noreferrer" target="_blank">http://lists.scsys.co.uk/cgi-b<wbr>in/mailman/listinfo/dbix-class</a><br>
IRC: <a href="http://irc.perl.org#dbix-class" rel="noreferrer" target="_blank">irc.perl.org#dbix-class</a><br>
SVN: <a href="http://dev.catalyst.perl.org/repos/bast/DBIx-Class/" rel="noreferrer" target="_blank">http://dev.catalyst.perl.org/r<wbr>epos/bast/DBIx-Class/</a><br>
Searchable Archive: <a href="http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk" rel="noreferrer" target="_blank">http://www.grokbase.com/group/<wbr>dbix-class@lists.scsys.co.uk</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><span style="font-size:12.8px">fernan</span></div></div></div>
</div>