[Dbix-class] GOVERNANCE: Aggregation and conclusion

[Darin McBride]

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?

If other DBIC modules that exist on CPAN need updating to work with DBIC2 
(presumably, they could work against both DBIC and DBIC2), what updating is 
it?  What can DBIC2 do to minimise this?

Presumably, some plugins out there are "stable" already and their authors may 
have already abandoned them, more or less, is this split going to be a make-
work project, with much angst and gnashing of teeth just to get all the 
plugins various DBIC2 users are using updated on CPAN?

If changes need to be made, is there something reasonable that an end-user who 
switches can do to monkey-patch things so that DBIC plugins will work with 
DBIC2?

Is DBIC2 going to be able to co-exist with DBIC?  Not merely on CPAN, but also 
on a user's perl installation?  I'm presuming this would be the plan, but I do 
want to ask.

I think this information would greatly impact my ability to vote.  Basically, 
how broken is someone if they go with the very first DBIC2 release?  If it will 
take 2 or 3 years from the first DBIC2 release until the ecosystem supports it 
well enough to make it viable for end-users to switch, I would think the split 
would then be basically DOA - it would be entirely moot.  On the other hand, 
if there is a list of 5 or fewer steps that users would need to do to start 
work with it, including all plugins (e.g., "in your code, switch this use 
statement to that, and call this monkey-patch function against your plugins"), 
it would tighten the feedback loop to at least make it viable.  Further, if 
there is a nice cargo-cult-style chunk of code that plugins can use to auto-
select between DBIC and DBIC2 support, right from that first release, it would 
greatly aid in the transition speed.  If, however, no plugin can support both 
DBIC and DBIC2 simultaneously without duplicating code or other code smells, 
then we would want to really think carefully about advocating a split.  I just 
don't know.


I think a secondary set of questions are also in need of asking, though final 
decisions on these likely can be deferred to consensus should the split be 
approved.  Questions such as whether fixes found in DBIC2 that also affect DBIC 
would be offered, whether as patches or pull requests or whatever format riba 
would want them in, back to DBIC as a matter of default policy (this does not 
tie riba's hands to actually accept them).  And, if riba doesn't accept them 
as is but fixes the same problem in another way, would that be merged back to 
DBIC2?  Another question here would be whether DBIC updates in general would 
be merged into DBIC2.  Having default positions on these from the "split" 
side, should it exist, would show priorities as well as indicate whether votes 
need to be taken, i.e., if the reverse from the default were being proposed.