Decision time: which fork inherits the existing DBIx::Class namespace

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Decision time: which fork inherits the existing DBIx::Class namespace

Peter Rabbitson-2
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@...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Decision time: which fork inherits the existing DBIx::Class namespace

Chisel

Run in, throw new contentious topic into room, run away to "take a break".

There's a part of me that was desperately trying to sit on the fence over the last few weeks but it's really starting to feel like every time the discussion gets close to some agreement you chuck something in to muddy the water and stir things up again.

While I appreciate the immense amount of time and effort you've put in to DBIC, I'm tired of this now.

We are/have been discussing the current DBIx::Class dist.

We should continue discussing the current DBIx::Class dist.

We should NOT talk about some hypothetical DBIx2::Class dist.

My "vote" now goes for "give DBIx::Class admin rights  to mst, and proceed with the team governance proposed".

Then, when you have the time and energy, you can (quietly) fork your SuperCautious::DBIx::Class dist.
You can work on this as quickly or slowly as you like, as quietly or loudly as you like.

This might allow us to come to a conclusion for the current DBIx::Class and not still be arguing about it until the end of 2017.

I think people have been more than reasonable but it's time to stop waiting days or weeks to hear your next round of argumentative thoughts, and work on a schedule that suits the majority, not the one.

Sorry, I'm just sick of all this ****, and want to move forward.


On Sat, 3 Dec 2016, 06:42 Peter Rabbitson, <[hidden email]> 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@...

_______________________________________________
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@...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Decision time: which fork inherits the existing DBIx::Class namespace

Pedro Melo
In reply to this post by Peter Rabbitson-2
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" <[hidden email]> 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@...
   

_______________________________________________
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@...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Decision time: which fork inherits the existing DBIx::Class namespace

Darren Duncan
In reply to this post by Peter Rabbitson-2
As per Chisel and Pedro Melo's responses to Peter Rabbitson's latest post, I
agree now that MST's proposal should govern the DBIx::Class namespace as what
"cpan DBIx::Class" resolves to, and users wanting Peter's fork can update their
dependency lists per his proposal.  Assuming Peter's on-install trick can work
both ways, we have room in the future to revisit what "cpan DBIx::Class"
resolves to in the future, but for now I propose MST's gets it. -- Darren Duncan


_______________________________________________
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@...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Decision time: which fork inherits the existing DBIx::Class namespace

James E Keenan
On 12/03/2016 04:48 AM, Darren Duncan wrote:
> I agree now that MST's proposal should govern the DBIx::Class
> namespace as what "cpan DBIx::Class" resolves to, and users wanting
> Peter's fork can update their dependency lists per his proposal.

That's my position, too.  Let's move forward.

Jim Keenan

_______________________________________________
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@...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Decision time: which fork inherits the existing DBIx::Class namespace

Sam Kington
In reply to this post by Peter Rabbitson-2
Hi,

Delurking; I’ve been following the discussion but haven’t said anything previously because I haven’t historically been part of the DBIx::Class community, nor have I been using the distribution for that long.

Also, I’ve struggled to understand what Peter Rabbitson’s problem with Perl, CPAN authors and the likes has been, despite reading a number of his blog and mailing list posts. This first bit is another example of such:

On 3 Dec 2016, at 05:50, Peter Rabbitson <[hidden email]> wrote:
> 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.

…and then he just leaves it at that.

Well, at some points you just have to say “it’s not me, it’s you”. I have no idea what that means, but Peter’s clearly not interested in explaining. No doubt this all makes sense in his head, and to the small handful of people who have been arguing with Peter for years on this subject, but it leaves me none the wiser.

But OK, not everyone is a trained writer, and by all accounts Peter’s technical skills are superb. So I was intrigued to hear this next bit:

> 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.

…and again nothing. How will this cunning plan work? What does “safe-by-default conflict-resolution at install time” even mean? Will it work for people installing DBIx::Class or support modules via Linux distributions’ package managers, not just via CPAN.pm, cpanm or similar? Given that Peter also wants the PAUSE rights to the DBIx::Class namespace (which makes me wonder why he’s even talking about the name of the fork if he wants to still call it DBIx::Class), is there any reason why Peter’s DBIx::Class would even have to care about this stuff at all?

The time for something like this was months ago when the split was first mooted. Now it feels, wilfully or not, like vapourware.

Sam
--
Website: http://www.illuminated.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@...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Decision time: which fork inherits the existing DBIx::Class namespace

Christian Walde
In reply to this post by Peter Rabbitson-2
On Sat, 03 Dec 2016 06:50:45 +0100, Peter Rabbitson  
<[hidden email]> wrote:

> I am essentially obligated to
> kickstart a DBIx::Class fork free of "community bias"
>
> The distribution will be governed by the proven BDFL model
>
> 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:
> 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.

This seems strongly reasonable to me, and i thank you for making an  
absolutely clear statement on the matter.

 From this going forward, it'll be easy for everyone to know what's at  
stake, seriously consider whether they wish DBIx::Class to be the riba  
fork or the team fork, and state so when the opinions are tallied.

I am particularly pleased be the fact that the question is just one of  
naming, and not one of blocking one of them from existence.

--
With regards,
Christian Walde

_______________________________________________
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@...
Sam
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Decision time: which fork inherits the existing DBIx::Class namespace

Sam
In reply to this post by Peter Rabbitson-2
Please don't fork it :(
It is nice that Perl has one good ORM that everyone uses. I don't want
to end up like Python and have 3 or 4 mediocre ORM's

--Sam


On 12/02/2016 11:50 PM, Peter Rabbitson 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@...


_______________________________________________
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@...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Decision time: which fork inherits the existing DBIx::Class namespace

Jonathan Scott Duff
In reply to this post by Peter Rabbitson-2

On Fri, Dec 2, 2016 at 11:50 PM, Peter Rabbitson <[hidden email]> wrote:
Greetings,

Greetings and salutations to you Peter  :-)
 

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 ).

Hmm.  This is unfortunate.  Even if the fork is for the good of the user base,
there will still be confusion about which DBIx::Class is the "right" or "best"
one from existing users and potential future users.  And what would be
available to help developers explain this fork to their managers (especially if
the list of dependencies does change as mentioned below)?
 

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.

I'd be interested in hearing more about how the fork would be providing the
DBIx::Class namespace safely.  If someone were to switch from one
DBIx::Class to the other, how difficult would that be?

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.

My vote would be for "cpan DBIx::Class" to install the team-led DBIx::Class.
I am swayed by pragmatism and the bus number arguments.

-Scott

_______________________________________________
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@...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Decision time: which fork inherits the existing DBIx::Class namespace

Dave Cross-2
In reply to this post by Chisel
On 03/12/2016 08:36, Chisel wrote:

> Sorry, I'm just sick of all this ****, and want to move forward.

+1

I'm already on record as supporting mst's community-lead version of the
project. I thought we'd pretty much reached a concensus on that a month
ago and I really don't understand why this is still dragging on.

Dave...

_______________________________________________
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@...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Decision time: which fork inherits the existing DBIx::Class namespace

Karen Etheridge
Me too.

Since now we know that Peter has nothing more to add to the proposal, let's get on with it.

On Sat, Dec 3, 2016 at 12:23 PM, Dave Cross <[hidden email]> wrote:
On 03/12/2016 08:36, Chisel wrote:

Sorry, I'm just sick of all this ****, and want to move forward.

+1

I'm already on record as supporting mst's community-lead version of the project. I thought we'd pretty much reached a concensus on that a month ago and I really don't understand why this is still dragging on.

Dave...


_______________________________________________
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@...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Decision time: which fork inherits the existing DBIx::Class namespace

Darren Duncan
In reply to this post by Sam
On 2016-12-03 9:27 AM, Sam wrote:
> Please don't fork it :(
> It is nice that Perl has one good ORM that everyone uses. I don't want to end up
> like Python and have 3 or 4 mediocre ORM's

Not to worry Sam, I don't believe this fork will result in a situation any worse
than what we have now.  This fork will not cause Perl's ORMs to all become mediocre.

Also, DBIx::Class is not the only good ORM for Perl.  I would say that at least
Rose::DB also qualifies as a good alternative; they both continue to be
maintained and I have used both.  Besides which, we don't really want a
mono-culture situation.  As good as DBIx::Class or Rose::DB or etc are, there is
always room for a new entry to come out that is better than either.

-- Darren Duncan


_______________________________________________
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@...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Decision time: which fork inherits the existing DBIx::Class namespace

Ashley Pond V
More options are always better and the acrimony over a win-win
situation is more telling than anything else that’s been said.

_______________________________________________
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@...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Decision time: which fork inherits the existing DBIx::Class namespace

Dave Cross-2

On 03/12/16 23:16, Ashley Pond V wrote:
> the acrimony over a win-win
> situation is more telling than anything else that’s been said.

What does that mean?

Dave...

_______________________________________________
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@...
Loading...