Peter,
As much as I appreciate your work and all the help you’ve provided me over the
past years as a user of DBIC, and as much I rather prefer a stable DBIC as a
primary goal, this response is not good enough for the rest of the community.
We do need closure on this topic, and move forward.
Movement for movement sake is not the issue, but we cannot wait more for a
resolution. I hope you understand this.
I look forward to your future projects with DBIC, and even adjusting my code to
use a new namespace if the end result is as good as your technical abilities
have proven in the past to be, but for the good of the large amounts of code
that assumes DBIx::Class as a dependency, I will hence forward support mst
proposal and keep the DBIC namespace with him and the team he suggested. I do
not think we should put the onus of picking a namespace winner in the hands of
the PAUSE admins, no matter the respect and trust they have rightfully earned
over time, I don’t think is fair of us to ask them for that kind of
Solomon-style decision.
Best regards,
On 03/12/16 05:50, "Peter Rabbitson" <rabbit+d...@rabbit.us> wrote:
Greetings,
The discussion so far has been centered around "fork or not?" I regret I
failed to address this early on, so here is my attempt at fixing that.
I spent the better part of last month wondering "how" and then "if" I
should respond to everything said so far. In the end I elected not to do
so at this time: it won't help anyone decide anything. I will address
the baseless personal allegations after the dust settles.
I do, however, firmly believe that Matt's perspective[1] of:
> I don't really think open source is *about* the people developing as
> such. What I think is that open source is *made of* the people
> developing it
is more or less an embodiment of what is wrong with the Open Source
industry today.
As such, and despite protests[2], I am essentially obligated to
kickstart a DBIx::Class fork free of "community bias" ( note:
"community", which was clearly set apart from "user base" in the past
months ).
The distribution will be governed by the proven BDFL model, although a
lot of the details will get formalized in a document supplied with the
distribution. The effect of uncertainty in this area turned out to be
too great not to address going forward.
The name of the fork is not interesting - the important thing is that it
will continue providing the DBIx::Class namespace ( via a novel method,
with safe-by-default conflict-resolution at install time, very much
*un*like the Alt convention ). This means that a user willing to
"switch" will have to adjust nothing more than their list of dependencies.
With all that said the outstanding question to the user-base is: given
that a fork is unavoidable, and given technical means allow both forks
to coexist on CPAN you must come to an agreement and instruct the PAUSE
admins which of the two (mildly incompatible dists) should `cpan
DBIx::Class` be resolving to.
I am taking a break from the entire brouhaha and am planning to start
work sometime in mid January. You have the holiday season and then some
to figure this out.
Cheers
[1] http://lists.scsys.co.uk/pipermail/dbix-class/2016-November/012426.html
[2] http://www.nntp.perl.org/group/perl.modules/2016/10/msg96348.html
_______________________________________________
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
_______________________________________________
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
