On 10/30/2016 02:47 AM, David Golden wrote:
On Sat, Oct 29, 2016 at 3:17 PM, Matt S Trout <m...@shadowcat.co.uk <mailto:m...@shadowcat.co.uk>> wrote:As such, I hereby call upon the PAUSE administration to adjust the permissions for all namespaces within the DBIx::Class distribution in accordance with: http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/012365.html <http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/012365.html> I'm very pleased to see how the DBIC community has engaged in honest discussion about self-governance. It's been a long road, but one that I think will serve the community well going forward.
I am pleased with the discussion that took place as well: it highlighted unambiguously the rift between two main groups of users. Having on record where various participants stand, including their extended position is an invaluable resource to have going forward.
I'll make the changes in the next 24-48 hours and make a final announcement when it's done.
However I find David's outlined course of action appalling. During the discussion advocates of a development speedup articulated multiple times in no uncertain terms that slavish catering to existing codebases will take a backseat. The certainty of this was so great that it prompted me to re-commit to keep working on the project in the same manner as it was led in the past ~4 years. There was a sizable support for this sort of arrangement.
Imagine my surprise when the PAUSE admins (after already having prevented me from taking my long-deserved retirement by scuttling my original plan) are informing me that my ownership of the project will be taken away by fiat anyway.
David, I realize that at this point you will do whatever it is you want to do. I am simply putting it on record that the transfer is happening against my will, and to a long-term (likely catastrophic) detriment of the existing userbase of DBIx::Class.
Additionally I believe the current group of PAUSE admins embarrassingly failed their first real accountability test. I strongly suggest revisiting your processes at the next QA Hackathon: the way you currently handle things "by ear" is absolutely unworkable going forward.
