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

[Matt S Trout]

On Tue, Oct 04, 2016 at 08:20:51PM +0200, Peter Mottram wrote:
> On 04/10/16 19:08, Matt S Trout wrote:
> > On Tue, Oct 04, 2016 at 12:49:49PM -0400, Ashley Pond V wrote:
> >> I did say MST RFC:MUST be respected. :P This is only here because of
> >> you. I was an early CDBI user and was there for the fights over its
> >> direction and saw you as the voice of reason, patience, and vision.
> >> Regardless of work done since, I see you as the owner. I was unaware
> >> there was as much of a schism as there apparently is.
> >>
> >> I don't know which approach is better. I feel the "permanent
> >> development ban" you assert is misrepresenting the situation.
> > Well, I'm not sure how else I can interpret riba's call for a 'project
> > freeze', especially given that in
> >
> > http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/012210.html
> >
> > he appears to feel that the previous contributors attempting to continue
> > the project is "the worst possible direction, one I worked really hard to
> > save this codebase from."
> My reading is more that this:
> 
> /> Really, if people upgrade, />/and encounter an issue .. they can either downgrade and wait, or pitch in />/and help (or pay someone to).. this is open source after all./
> 
> is not a viable option if the breakage causes data loss.

Please do remember that I'm the one who originally started a stable release
cycle, with vast attention to compatibility issues, because the idea of
damaging somebody's production data scares the crap out of me.

In fact, the only reason ribasushi became chainsaw delegate was because for
the first time I'd found somebody I trusted to be as worried about the
potential for data loss as I was.

> Some projects can afford to be much more
> bleeding edge but I feel that DBIx::Class needs to be paranoid about
> what is accepted in core. After all there are other options to allow
> features to be added without touching core.

The policy of DBIx::Class, as originally set by me, has always been that if
it can be done outside of core, it should be done outside of core.

I'm not sure what sort of cowboy future you're imagining but it certainly
isn't what any of the contributors signed up for, or what any of us have in
mind.

-- 
Matt S Trout - Shadowcat Systems - Perl consulting with a commit bit and a clue

http://shadowcat.co.uk/blog/matt-s-trout/   http://twitter.com/shadowcat_mst/

Email me now on mst (at) shadowcat.co.uk and let's chat about how our CPAN
commercial support, training and consultancy packages could help your team.