[Dbix-class] Let's call things what they are 2/2

[Peter Rabbitson]

On 10/11/2016 08:55 PM, Darren Duncan wrote:
>
> So the only good reason I can think of to not more effectively give the
> DBIC users the fruits of your labor to date, by (simply?) cutting a CPAN
> release, is that you are concerned that said changes as is might break
> something for users that currently works, and then someone with the
> desired stability mindset won't be around to deal with fixing that in a
> timely manner.

Sigh... let me make it as clear as possible:

- I consider the current tip of the dbsrgits repo[1] safe to use in 
production. It has already been successfully tested against a massive 
amount of downstream deps[2], and is being used in several select 
darkpan outfits.

- The work was undertaken in a manner making it virtually impossible for 
silent/latent (not instantly obvious) breakage to creep in.

- Breakage itself is always a risk, and can not be 100% avoided. I have 
applied everything in my toolbox to mitigate the potential, but it is 
still there: it would be silly to claim otherwise.

- I *will* be available to fix currently unknown problems in a timely 
manner. In case the code is taken forward by someone, I will be 
available for an indefinite period of time to answer questions, and in 
some limited cases to produce fixes to whatever is uncovered in the 
process of wider use. Such support will be carried out either on this 
mailing list or via the already-existing publicly logged(!) support 
channel[3]. For the foreseeable future I will continue to be available 
during a pre-defined "office hours" window, currently at Mon-Fri 
15:00~16:30 UTC. My longer term involvement is also somewhat guaranteed 
by the fact of my $paying_job being a DBIx::Class user, thus I have a 
vested interest in the codebase not driving off a cliff (though this 
interest is in the role of a user, not former codebase owner).

- Given the new realities of the future of this namespace (all of which 
I was not aware of until [4]), I can not proceed with my original plan 
as stated multiple times in this thread. Doing otherwise ( by further 
committing to the repository and/or shipping stuff to CPAN under a 
group-controlled namespace ) would imply tacit endorsement of the 
currently presented proposal for the project governance. I will not do that.

>
> Whereas, if I am wrong and the primary reason against releasing your
> existing work isn't about the risk of breaking things for users, then I
> don't understand why the future DBIC governance has any bearing on what
> you can do right now.
>

The link between *future* governance and *current* code is everything. 
The current and future attitudes within CPAN as a whole is the very 
reason I am distancing myself from various pieces I have been ( I 
believe positively ) involved in.

It is like asking me why I am suddenly heading to the nearest exit half 
way through preparing the dessert of a 10 course meal on board of what I 
thought is the RMS Olympic, once I am most casually informed that we are 
in fact on board her sister-ship.

Darren, you are correct - there is no *direct* provable link between 
what is now and what is tomorrow. On the other hand being pretty good at 
extrapolating and evaluating potential outcomes is what makes us human 
in the first place. Forgive me for being one.

[1] https://github.com/dbsrgits/dbix-class/commit/dc7d8991
[2] https://github.com/dbsrgits/dbix-class/commit/12e7015a
[3] https://irclog.perlgeek.de/askriba/2016-10-12#i_13382567
[4] http://www.nntp.perl.org/group/perl.modules/2016/09/msg96139.html