[Dbix-class] GOVERNANCE: Aggregation and conclusion

[Dmitry Bigunyak]

>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.
>
>The advantages of this proposal are:
>
>1. Users get a choice. If they are happy with the current feature set
>and need rock-solid performance and stability, then they can use DBIC.
>If they need new features or want to use a module that has a quicker
>development pace, then they can use DBIC2.
>
>2. Ribasushi continues to contribute to the code base, both in terms of
>potentially migrating proven-solid features from DBIC2 to DBIC, and in
>terms of keeping his expertise engaged.
>
>Andy
>

+1 to the "fork proposal" as the solution which should satisfy most of the people.
I don't really share concerns regarding the team fragmentation, instead having a choice and maybe even healthy competition is definitely a good thing.

--
Dmitry Bigunyak