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

_______________________________________________
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

Reply via email to