Hello, all.

I don't talk here much, because of the excellent work done by the DBIC teams 
over the years.  I've read along and learned a lot, though, and used DBIC 
professionally.

First, thank you to mst, Ribasushi, and all the other contributors for their 
hard work in stabilizing DBIC and making it the robust, dependable, reliable 
thing it is today.  I know how much work that is, and am not sure anyone says 
that very often.  It is a really excellent piece of software which is a great 
contribution to the Perl community and the larger world.

I mean that; I work at a large hardware company you have probably heard of.  
Our hardware is used for, among other things, sequencing new treatments for 
cancer.  We couldn't build these massive chips without the build tools written 
in Perl and using DBIC.  You really are making the world as a whole a better 
place.

I'm sorry to see this dispute.  It's a sign that someone or several people in 
the community are deeply unhappy, and that something we all took for granted 
isn't working.  That's painful, and needs to be fixed.  I think Ribasushi's 
done the right thing by taking care of himself and starting the conversation to 
get out of this position.  That doesn't mean I think he should take his ball 
and go home, freezing the codebase and leaving everyone stuck, but that he 
needs to get himself out of something that's become untenable for him.

(more below...)

> On Oct 4, 2016, at 1:59 PM, Matt S Trout <m...@shadowcat.co.uk> wrote:
> On Tue, Oct 04, 2016 at 09:43:56PM +0100, Leo Lapworth wrote:
>> On 4 October 2016 at 21:35, Christian Walde <walde.christ...@gmail.com> 
>> wrote:
>>> 
>>> 
<snip>
>>> You preparing your feature-frozen-bugfix-only release in a different
>>> namespace; mst's plan being used in the DBIx::Class namespace.
>>> 
>>> That way people who're worried can stick to a stable branch of dbic, and
>>> people who actually need more from DBIc at some point in the future aren't
>>> lost in limbo.
>>> 
>>> There's no need to deprive your stable-needing users of the work you had
>>> planned to do, nor your far future users of a useful library, if both can
>>> be served at the same time.
>> 
>> +1
> 
> Note that we have prior technical art for providing bundled versions of
> SQLA in dev releases which could absolutely be repurposed to allow for a
> 'use DBIx::Class::StabilityFreeze;' to work:
> 
> https://github.com/dbsrgits/dbix-class/blob/current/dq/lib/DBIx/Class/_TempExtlib.pm
> 
> (idea the result of discussion between riba and I, implemented by riba)


Is this really needed?

For our mission critical systems, we have versioning in place.  We don't move 
ahead until we've passed our acceptance tests.  DBIC is not usually an issue, 
but many Perl modules can be, and once you're protecting one, protecting them 
all is as easy as protecting one of them.  There are excellent tools out there 
to help with this, Pinto, Stratopan, perlbrew, etc.  This is not a new problem, 
and there are good solutions for it.

As long as DBIC tries to keep the release stable, and fixes user-facing issues 
quickly, the people who need it can move ahead when they're ready to, and be 
completely able to work.  Just like we do with Test::More, core Perl versions, 
and all the other modules we depend on.

I feel mst's proposed solution will keep the codebase stable, and let it remain 
vital and under development.  The risk is there, and the team approving and 
code-reviewing changes understands that.  Lots of testing and care, with good 
code-review will manage that risk, while allowing future development.  A 
closed-off DBIC just forces extra work onto all the users to migrate to the 
inevitable fork, for no concrete benefit.

Please don't lock DBIC down.


_______________________________________________
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