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] http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/012392.html [2] http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/012237.html _______________________________________________ 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
