[Dbix-class] GOVERNANCE: Aggregation and conclusion

Andrew Beverley andy at andybev.com
Mon Oct 31 11:22:07 GMT 2016


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



More information about the DBIx-Class mailing list