[Dbix-class] GOVERNANCE: Aggregation and conclusion

Darren Duncan darren at darrenduncan.net
Mon Oct 31 21:24:17 GMT 2016


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



More information about the DBIx-Class mailing list