[Dbix-class] A slightly more concrete proposal

[Darren Duncan]

I agree with this proposal that Matt stated, it seems solid to me.

I will also say that I intend to be a significant DBIC contributor personally 
starting in the near future, estimated about 1 month from now.  Initially that 
will take the form of significant new core features developed in an experimental 
branch, which can then be evaluated by other community members and the core team 
for usefulness.  If accepted these can then be selectively merged into core or 
turned into extensions or inspire work by others as is best practice.  While 
large changes are anticipated as fruit, they are by design intended to be fully 
backwards-compatible with regular user code.

-- Darren Duncan

On 2016-10-04 1:17 PM, Matt S Trout wrote:
> Since people seem to be unsure as to what the alternative to riba's project
> freeze would actually be, let me provide something a little more concrete.
>
> This is intended as a basis for discussion rather than a complete plan, but
> I thought it was worth at least sketching a shape for things to come.
>
> 1) I think at this point we should formalise a core team. The BDFL model
> was nice while it lasted, but I don't think it's tenable going forwards.
>
> My first thought for composition would be a five-person team, and assuming
> everybody agrees to it,that being Ilmari, Castaway (Jess Robinson), Frew,
> myself, and whoever riba was planning to pass the first-come bits to.
>
> That seems like it should be a nice combination of continuity and ensuring
> that riba's fears we'll be insufficiently conservative being given a voice.
>
> Exactly what would require a formal vote I leave as an open question for the
> moment since it boils down to "what would leave both us and the userbase
> comfortable things were being properly managed" and that'd require discussion.
>
> 2) I certainly wouldn't expect to be merging any clever branches any time
> soon - understanding the work that riba did in private without discussion is
> going to take time, since while his motivations were good the effect on us
> is similar to the effect of taking over from a developer being territorial
> in the name of job security - so keeping to careful bugfixes only for at
> least the first six months is likely to be the only sensible approach.
>
> 3) New feature development will need to be approached carefully, and I
> think we'll need to ensure we have a proper code review procedure in place
> before merging things into master. Of course, public branches plus lots
> of dev releases will also help, as will approaching this as an additive
> process where as far as possible the existing logic remains untouched
> until we're confident we understand what's going on where.
>
> 4) I still remember the fear induced adrenaline surge a little over a decade
> ago when I realised that because I wasn't doing regular releases yet, people
> were deploying svn trunk against their production database. That's how we got
> a regular release cycle and a commitment to backcompat - I have, if anything,
> always been more scared of data loss than the average of the user base, to
> the point where I got threats from users to fork because we were being too
> slow and conservative about adding features. I still believe in that, and
> I think so do castaway/frew/ilmari.
>
> 5) I continue to believe that things that can be done outside of core should
> be done outside of core, and that if at all possible we should prototype
> APIs and feature sets in extensions first even if they'd be better served
> being in core, but equally, if you look at the limitations of and the insane
> code required in http://p3rl.org/DBIx::Class::ParamaterizedJoinHack you can
> see that there are still things that core does not yet make as elegant and
> robust as one might prefer, and I think it's worth at least trying to
> improve on that.
>
> Hopefully that gives people a clearer idea of what I think would end up
> happening if we decide to move forwards once again as a team project.
>