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
