[Dbix-class] GOVERNANCE: Aggregation and conclusion

[Darin McBride]

On Wednesday November 2 2016 11:38:35 PM Matt S Trout wrote:
> 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.

Yes, we see JSON, JSON::XS, JSON::PP all with a single JSON interface, and 
magic happening under the covers. However, because, in theory, all of these 
will provide *exactly the same functionality* and interfaces, only a 
performance difference, that's fine.  Since the goal of DBIC / DBIC2 is to 
diverge, I don't think I'd want to see them "automatically" work for the end 
user.  There should, IMO, be some level of action required by the end user to 
say "I want DBIC2."  Otherwise there is literally no reason for forking.  Even 
if it were "use DBI::Class 2;" (which, obviously, would require active co-
operation, but doesn't really gain us anything over "use DBI::Class2;")

I'm more thinking of the Mo/Moo/Mouse/Moose compatibility, where, with the 
right incantations in plugins/other modules, they can work with any of the 
above, and the application developer at the end can choose which one to use.  
At least some plugins can, obviously plugins that require the heavier feature 
set of Moose won't work with Moo, and that's okay.

Anyway, my question is more pointed at how broken, or not, the rest of the 
DBIx::Class namespace would be in a DBIC2 application, especially one that was 
working with DBIC and wants to convert to DBIC2.  If much carnage is expected, 
then that would affect the voting, I imagine.  Or maybe I'm alone on this.

(I think it is obvious that many applications won't convert, and that's fine, I 
would hope and expect no breakage there through any "conversion" process 
here.)

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