[Dbix-class] GOVERNANCE: Aggregation and conclusion

[Fernan Aguero]

+1 for the fork

On Mon, Oct 31, 2016 at 6:24 PM, Darren Duncan <darren at darrenduncan.net>
wrote:

> My current thought is that a fork may be the best solution in the short
> term, with the following clarifications or amendments.
>
> 1. Peter Rabbitson would have the exclusive PAUSE permissions to the
> DBIx::Class namespace and would continue to perform releases of his work on
> it as he wanted to do.  He would also designate others to have those
> permissions as he chooses, and he would choose his own successor.  This
> namespace would emphasize stability and/or Peter's objectives.
>
> 2. Matt would create a fork using his proposed governance model to further
> evolve along those lines.  The fork would emphasize their objectives, and
> would probably include most major work not done by Peter.
>
> 3. I hope that Peter would still be open to pull requests but he should
> publish some documentation giving an outline of what qualities he would
> look for in patches from others so they would more likely be accepted.  My
> assumption however, is that in a fork scenario most pull requests would
> just go to the fork, and pull requests on the original would be limited to
> small things like security or bug fixes.
>
> 4. In the future, if Peter decides to leave again and/or there is no
> successor, the DBIx::Class namespace can be treated according to abandoned
> module protocol, where Peter has no outstanding interest, unlike now.
>
> 5. Ideally DBIC, both versions, would be as duck-typed as possible with
> its API, so that dependent modules or applications could switch between
> them more easily, without having to do a lot of tests on the names of
> classes.
>
> This all being said, I am ALSO fine with Matt's governance proposal being
> used with the DBIx::Class namespace, though given that Peter's further
> committer involvement is basically mutually exclusive with this, I consider
> it less ideal for that reason.
>
> I also recognize that DBIC has its own network of extensions, and I don't
> know if they are duck-typed or not, eg would they themselves need
> substantial or any changes to work in a forked ecosystem, or if one could
> use them with both different-names DBIC versions unchanged.
>
> I see that as a main complicating factor.  Applications, not so much; if
> they want stability, Peter's version should serve them; if they want
> substantial changes or new features that more likely may be in the fork,
> they would have to be changed anyway.
>
> -- Darren Duncan
>
>
> _______________________________________________
> 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/90e54c9d/attachment.htm>