[Dbix-class] IMPORTANT: A discussion of DBIC governance and future development

[Michael Hamlin]

(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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scsys.co.uk/pipermail/dbix-class/attachments/20161007/5ff9fdb9/attachment-0001.htm>