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