[Dbix-class] GOVERNANCE: Aggregation and conclusion

[Matt S Trout]

On Wed, Nov 02, 2016 at 04:32:31PM -0600, Darin McBride wrote:
> On Monday October 31 2016 11:22:07 AM Andrew Beverley wrote:
> > On Mon, 31 Oct 2016 00:43:31 Matt S Trout <mst at shadowcat.co.uk> wrote:
> > > Otherwise, I would suggest that you turn your plan into a full
> > > proposal,
> > 
> > TBH, I didn't even realise I was making a proposal until I saw the
> > results[1]. I was merely bringing up one of Dave's earlier
> > suggestions[2], which several others also seemed to like.
> > 
> > But, in that case, I propose:
> > 
> > - RIBASUSHI retains the current namespace, continuing to maintain and
> > tighten that code base. The aim would be a rock-solid module with a
> > very conservative rate of change and new features.
> > 
> > - A new namespace DBIx::Class2 is created, owned and operated by MST's
> > governance+core team proposal. Developers that want to create new
> > features do so in this namespace.
> > 
> > I do not understand the technicalities, but from what I have seen
> > discussed, people would still be able to use DBIx::Class::* modules in
> > both namespaces.
> 
> There is one piece missing, IMO.  The rest of CPAN.  Maybe there's a simple 
> solution, maybe this is a non-issue.  But, not knowing the internals of DBIC 
> plugins, I'm going to ask the dumb questions.
> 
> 
> As a user of DBIC, let's say I want to go with the "dangerous" DBIC2 instead 
> of the stable DBIC.  It has some feature I really want that just got released 
> next year some time.  However, I have a bunch of DBIx::Class plugins as well.  
> Do the plugins Just Work (TM) with DBIC2 despite the namespace change?  
> Obviously, my own code needs to derive off a new set of base classes, which I 
> sort of asked for by virtue of switching.  Ideally, that'd be it - but is it?

Actually, I think it can potentially be done without needing to force people
to s{}{} their superclass lines, but only given active co-operation between
the people developing both.

Any other approach will, I think, inevitably result in the same sort of
troubles the Dancer/Dancer2 split caused (I argued for managing to maintain
sufficiently backwards compatibility in the new codebase to not require the
split; I lost).

Given I think it's fairly clear at this point that "active co-operation" is
unlikely to describe the relationship between riba and I going forwards, I
hope this explains why I don't consider myself suitable to be involved in
a fork.

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