>On Mon, 31 Oct 2016 00:43:31 Matt S Trout < m...@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 _______________________________________________ List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class IRC: irc.perl.org#dbix-class SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/ Searchable Archive: http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk
