<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 2, 2016 at 11:50 PM, Peter Rabbitson <span dir="ltr"><<a href="mailto:rabbit+dbic@rabbit.us" target="_blank">rabbit+dbic@rabbit.us</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Greetings,<br></blockquote><div><br></div><div>Greetings and salutations to you Peter :-)<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
As such, and despite protests[2], I am essentially obligated to<br>
kickstart a DBIx::Class fork free of "community bias" ( note:<br>
"community", which was clearly set apart from "user base" in the past<br>
months ).<br></blockquote><div><br></div><div>Hmm. This is unfortunate. Even if the fork is for the good of the user base,<br></div><div>there will still be confusion about which DBIx::Class is the "right" or "best"<br></div><div>one from existing users and potential future users. And what would be <br>available to help developers explain this fork to their managers (especially if <br></div><div>the list of dependencies does change as mentioned below)?<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The distribution will be governed by the proven BDFL model, although a<br>
lot of the details will get formalized in a document supplied with the<br>
distribution. The effect of uncertainty in this area turned out to be<br>
too great not to address going forward.<br>
<br>
<br>
The name of the fork is not interesting - the important thing is that it<br>
will continue providing the DBIx::Class namespace ( via a novel method,<br>
with safe-by-default conflict-resolution at install time, very much<br>
*un*like the Alt convention ). This means that a user willing to<br>
"switch" will have to adjust nothing more than their list of dependencies.<br></blockquote><div><br></div><div>I'd be interested in hearing more about how the fork would be providing the <br>DBIx::Class namespace safely. If someone were to switch from one <br>DBIx::Class to the other, how difficult would that be?<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
With all that said the outstanding question to the user-base is: given<br>
that a fork is unavoidable, and given technical means allow both forks<br>
to coexist on CPAN you must come to an agreement and instruct the PAUSE<br>
admins which of the two (mildly incompatible dists) should `cpan<br>
DBIx::Class` be resolving to.<br></blockquote><div><br></div><div>My vote would be for "cpan DBIx::Class" to install the team-led DBIx::Class.<br></div><div>I am swayed by pragmatism and the bus number arguments.<br></div><div><br></div></div>-Scott<br></div></div>