[Dbix-class] Decision time: which fork inherits the existing DBIx::Class namespace

[Pedro Melo]

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+dbic at 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