[Dbix-class] IMPORTANT: A discussion of DBIC governance and future development

[Louis Erickson]

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 <mst at 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.christian at 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.