[Dbix-class] 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, <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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scsys.co.uk/pipermail/dbix-class/attachments/20161203/a38f711a/attachment.htm>