[Dbix-class] A slightly more concrete proposal

[Matt S Trout]

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.

-- 
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.