[Dbix-class] GOVERNANCE: Aggregation and conclusion

[Fernan Aguero]

+1 on this proposal.

everyone should be happy with this. From reading silently all the proposals
in this thread, it is clear that we all want DBIC to move forward, if that
means letting RIBA have the namespace and MST and the new governance to be
able to work on DBIC freely, then separating the namespaces is the most
sensible and pragmatic thing to do IMO.

If RIBA does not have time or willingness to keep working on DBIC or
contributing code, then the old namespace dies, as many other Perl modules
and namespaces do. It's called evolution.

The worst that can happen is active development in both namespaces, and
then having the problem of parallel (convergent, duplication of , efforts;
or divergent) in any case, paradoxically that would be a good thing!

But being a biologist by training, just let me say that we shouldn't care
too much about how the project will evolve. You cannot direct or guide
evolution, you just see it happen.

Let's not be dramatic about this, it happened to all the BSDs in the past.
FreeBSD, NetBSD, OpenBSD, ... forks for focusing a critical mass of
developers on different aspects (security, portability, etc). They still
share and exchange code and ideas, or even big architectural changes when
something developed by one project makes sense for all others.

Let's fork, let go of namespaces, and move on!

--
fernan

On Mon, Oct 31, 2016 at 8:22 AM, Andrew Beverley <andy at andybev.com> 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.
>
> 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 at lists.scsys.co.uk
>



-- 
fernan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scsys.co.uk/pipermail/dbix-class/attachments/20161031/0cca2af5/attachment.htm>