(Note: most of the below was written before Riba's most recent message, and is therefore perhaps now moot. Sorry I didn't get it out sooner.)
I rarely email a list or maintainer; I'm one of the many out here in DarkPAN who only occasionally check-in on the mostly public Perl world. Anytime I do email, though, I always begin with thanks. Thank you Riba for doing an outstanding job, fixing and adding features to a technically very complex codebase. It's clear that you took the responsibility to your (largely silent, i would guess) users very seriously, in terms of quality and backwards compatibility. You will probably never receive gratitude commensurate to your efforts, so it's important that I express mine. Every time I see you, the first beer is on me, agreed? (If genehack gets to you first, it will be the second!) I don't know that my thoughts have much value in this discussion. I am in the periphery of the Perl community. FWIW, my employer uses DBIx::Class heavily, and consequently I do. We were asked to consider a decision about governorship of the project. For me, the decision about who is less important than what the goals are. There are links, of course, between these questions. Riba was asked to be more clear about his intentions, presumably shared by his chosen successor. My impression from what I've read is that only security fixes and perhaps other small bug fixes would be considered. I would like a fuller description on how the line should be drawn, in his view. I like mst's description that what can stay out of core should stay out, and appreciate that he takes the responsibility for the project's stability seriously. However, it seems he's also thinking about new features, those may require changes in core. I'd like to hear more from mst about safely making larger changes, and his views on backwards compatibility. I would have concerns about significant architectural changes in this project. While not strictly against that, I would be more comfortable seeing those in a separate namespace (which is not without precedent, as xdg pointed out): a faster moving fork where new ideas, features, experiments are tried out. End users can decide which of the two is appropriate for new projects, while existing projects can migrate deliberately when they wish, or not. That sounds great, in theory. But there are significant costs to a split. As the goals are different, there would be a natural divergence between the packages, and without cooperation they could become incompatible. For the two packages to represent "stable" and "innovative" branches of the same project would require high degree of coordination between maintainers (or groups), such that each is partly responsible for the other, or that both packages were maintained by the same person or group. Then features could gradually migrate from the more adventurous module back into the stable one. I recognize maintaining two packages is more work; ultimately it comes down to what volunteers are willing to do. If new maintainers want to innovate, they should be encouraged to do so. If there is someone willing to maintain the existing module with small fixes only (as we have been given to believe), I think that would also be appreciated by many users. A split would allow both things to happen, which (seems to me) sort of the best situation, even knowing that eventually things look worse again when they become incompatible, or one project loses active stewardship. But that's a bridge to be crossed if/when we get there. Riba's retracting his original plan seems to make my idea moot. What sort of coordination between those with the different goals would be possible? I really would have liked to hear from Riba's chosen successor. Perhaps that person is no longer interested? michael P.S. Thanks to everyone just being involved, maintaining a viable ecosystem, caring about the silent masses out here. I sympathize with the emotional toll of this situation, and appreciate all efforts to resolve it responsibly, peacefully, and sensitively.
_______________________________________________ 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@lists.scsys.co.uk
