IMPORTANT: A discussion of DBIC governance and future development

I apologize in advance for the length of this email, but I urge everyone that uses DBIC to read it fully as it relates to the future of this important module.

For those who don't know me, I'm DAGOLDEN on CPAN and I've joined this list in my capacity as a PAUSE [1] administrator.

For those on the list who aren't familiar with CPAN administration, PAUSE is the service that authors use to upload modules to CPAN. Among other functions, it generates the index that maps modules names to downloadable tarballs – e.g. "DBIx::Class" to "RIBASUSHI/DBIx-Class-0.082840.tar.gz" on a CPAN mirror.

PAUSE also maintains a permissions model [2] for each module namespace with two levels: "primary maintainer" (also called "first come") and "co-maintainer" (aka "co-maint"). Primary maintainers can grant and revoke co-maint permissions. Both levels can upload tarballs to PAUSE, triggering an update to the index.

Over the past several weeks, I've been the PAUSE administrator selected to mediate a dispute over future disposition of primary permissions for the DBIx::Class namespace.

I have also firmly selected who will be getting the DBIx::Class namespace first-come[2], the transfer of which will also happen somewhere around the end of September.

Because the identity of the new primary maintainer was neither disclosed nor discussed with Matt Trout (the founder of the DBIC project, current co-maintainer and also PAUSE administrator) or other co-maintainers, several private conversations between ensued between Matt, Peter and others about this declaration.

On September 15, Peter notified PAUSE administrators via the [hidden email] mailing list of an "Upcoming PAUSE permissions dispute" [4]. Separately, Matt notified PAUSE administrators privately with his own concerns about a possible dispute (his email was later disclosed and I'll link to it later).

On September 21, I privately emailed all DBIC maintainers (CPAN authors ABRAXXA, ARODLAND, FREW, ILMARI, JROBINSON, MSTROUT, and RIBASUSHI) on behalf of PAUSE administrators with our collective view of how this dispute would be best resolved. Peter asked that any discussion be public, so I reposted it to the [hidden email] mailing list as "Message from PAUSE Admins to DBIx::Class maintainers [resend]" [5]

I urge everyone to read that thread in full as well. For reference, it includes a copy [6] of Matt's previously private email to PAUSE administrators.

Importantly, the thread summarizes PAUSE administrators' position on the dispute, which I repost verbatim here:

(1) Given the importance of DBIC to the broader Perl community (i.e. way"upriver" <http://neilb.org/2015/04/20/river-of-cpan.html>), we’d like tosee a more open discussion between existing maintainers about what happensnext in terms of DBIC leadership and control of primary permissions.

(2) The best outcome from our perspective would be for a successor to bedecided by consensus of existing maintainers.

(3) Given a dispute among maintainers, the only outcome that is absolutelyunacceptable to PAUSE admins would be a unilateral permissions transferdecision.

(4) We really hope the DBIC maintainers and/or community can resolve thisinternally.

In the ensuing discussion, Peter disclosed additional details about his plans for the future of DBIC in the "Future plans" section of this email [7]:

I am still planning to wrap up the remaining pieces, including some unannounced initiatives to get the project into the best shape possible to survive its leaderlessness.

I am still planning to remove all co-maint perms and handover the first-come to a yet-undisclosed person. Given no clear line of succession, and the incredibly high stakes wrt compatibility, the only responsible thing to do is to select a single spot of responsibility and provide all possible support and infrastructure for a proper project-freeze.

In another email [8], Peter suggested raising these issues explicitly on the DBIC mailing list:

As suggested in an earlier email: the PAUSE admins (as the only legitimate concerned party at this point) would likely benefit having this question asked in a wider forum ( the DBIC mailing list and/or other channels ). Essentially someone has to trigger a "vote of no confidence", otherwise this entire exchange is just a time consuming farce.

On behalf of the PAUSE administrators, we would therefore like to invite Peter to describe in more detail his plans for a "project freeze" and the role he envisions for a successor maintainer. We invite Matt, other co-maintainers, and the DBIC community at large to add their thoughts about the specifics of the plan or about the situation in general.

Given public and private discussions to date, we believe the DBIC community should consider questions such as:

How should the future governance of the DBIC project be decided?

Who should or shouldn't be involved in future governance?

Should the project be "frozen" or should development continue?

If "frozen", what specifically would a "freeze" entail? Would there be exceptions?

Re: IMPORTANT: A discussion of DBIC governance and future development

On 10/03/2016 10:37 PM, David Golden wrote:
>
> <snip>
>
> In the ensuing discussion, Peter disclosed additional details about his
> plans for the future of DBIC

Given the discussion generated way more interest than I anticipated, at
this point I am pausing all activity ( both code and administrative
changes ), until at least the 8th of October. I want to give ample time
for all interested parties to state their thoughts.

From my side, in order to highlight the main "point of contention" if
you will, I am pulling together several pieces from the aforementioned
threads:

> How much more concerning, then, to discover in the last few days
> that you have seen your DBIC-related activities since December as
> effectively winding up the project, rather than preparing to leave
> it to others.
> ...
> I know a bunch of the the pending changes are not ready to merge (or
> "sub-par" if you will); this is because I haven't had the motivation to
> put more work into them
> ...
> I suspect if we managed to get all of the branches
> people had planned that were delayed because riba's response to the proposed
> features was "yes, but please wait for me to finish X first" done then that
> work in itself might be a major release's worth.
> ...
> While I get that its (n.b. DBIC) depended on a fair bit, I don't think that
> means being *perfect* to the exclusion of all experimentation. I don't think
>I've come across other bits of CPAN, apart from maybe the ones in core, that
> attempt to be as rigorous in their perfection. Really, if people upgrade,
> and encounter an issue .. they can either downgrade and wait, or pitch in
> and help (or pay someone to).. this is open source after all.

While the project does not have a bright future under my (now likely
moot) plan, the approach indicated above is, in my opinion, the worst
possible direction, one I worked really hard to save this codebase from.

Nevertheless, if nobody else finds this problematic: I will step aside
and let an eager community, inadvertently suppressed all these years,
steer this project further.

Re: IMPORTANT: A discussion of DBIC governance and future development

Cathedrals are fabulously impressive places of important historical interest, but they become cold and abandoned. If you need to do day-to-day business you go to the bazaar, where latest gadgets for every taste can be found.

I'm the author of DBIx::Class::Schema::Loader::Dynamic. I hope I won't have to move that (imho essential) module to some different namespace.

I apologize in advance for the length of this email, but I urge everyone that uses DBIC to read it fully as it relates to the future of this important module.

For those who don't know me, I'm DAGOLDEN on CPAN and I've joined this list in my capacity as a PAUSE [1] administrator.

For those on the list who aren't familiar with CPAN administration, PAUSE is the service that authors use to upload modules to CPAN. Among other functions, it generates the index that maps modules names to downloadable tarballs – e.g. "DBIx::Class" to "RIBASUSHI/DBIx-Class-0.082840.tar.gz" on a CPAN mirror.

PAUSE also maintains a permissions model [2] for each module namespace with two levels: "primary maintainer" (also called "first come") and "co-maintainer" (aka "co-maint"). Primary maintainers can grant and revoke co-maint permissions. Both levels can upload tarballs to PAUSE, triggering an update to the index.

Over the past several weeks, I've been the PAUSE administrator selected to mediate a dispute over future disposition of primary permissions for the DBIx::Class namespace.

I have also firmly selected who will be getting the DBIx::Class namespace first-come[2], the transfer of which will also happen somewhere around the end of September.

Because the identity of the new primary maintainer was neither disclosed nor discussed with Matt Trout (the founder of the DBIC project, current co-maintainer and also PAUSE administrator) or other co-maintainers, several private conversations between ensued between Matt, Peter and others about this declaration.

On September 15, Peter notified PAUSE administrators via the [hidden email] mailing list of an "Upcoming PAUSE permissions dispute" [4]. Separately, Matt notified PAUSE administrators privately with his own concerns about a possible dispute (his email was later disclosed and I'll link to it later).

On September 21, I privately emailed all DBIC maintainers (CPAN authors ABRAXXA, ARODLAND, FREW, ILMARI, JROBINSON, MSTROUT, and RIBASUSHI) on behalf of PAUSE administrators with our collective view of how this dispute would be best resolved. Peter asked that any discussion be public, so I reposted it to the [hidden email] mailing list as "Message from PAUSE Admins to DBIx::Class maintainers [resend]" [5]

I urge everyone to read that thread in full as well. For reference, it includes a copy [6] of Matt's previously private email to PAUSE administrators.

Importantly, the thread summarizes PAUSE administrators' position on the dispute, which I repost verbatim here:

(1) Given the importance of DBIC to the broader Perl community (i.e. way"upriver" <http://neilb.org/2015/04/20/river-of-cpan.html>), we’d like tosee a more open discussion between existing maintainers about what happensnext in terms of DBIC leadership and control of primary permissions.

(2) The best outcome from our perspective would be for a successor to bedecided by consensus of existing maintainers.

(3) Given a dispute among maintainers, the only outcome that is absolutelyunacceptable to PAUSE admins would be a unilateral permissions transferdecision.

(4) We really hope the DBIC maintainers and/or community can resolve thisinternally.

In the ensuing discussion, Peter disclosed additional details about his plans for the future of DBIC in the "Future plans" section of this email [7]:

I am still planning to wrap up the remaining pieces, including some unannounced initiatives to get the project into the best shape possible to survive its leaderlessness.

I am still planning to remove all co-maint perms and handover the first-come to a yet-undisclosed person. Given no clear line of succession, and the incredibly high stakes wrt compatibility, the only responsible thing to do is to select a single spot of responsibility and provide all possible support and infrastructure for a proper project-freeze.

In another email [8], Peter suggested raising these issues explicitly on the DBIC mailing list:

As suggested in an earlier email: the PAUSE admins (as the only legitimate concerned party at this point) would likely benefit having this question asked in a wider forum ( the DBIC mailing list and/or other channels ). Essentially someone has to trigger a "vote of no confidence", otherwise this entire exchange is just a time consuming farce.

On behalf of the PAUSE administrators, we would therefore like to invite Peter to describe in more detail his plans for a "project freeze" and the role he envisions for a successor maintainer. We invite Matt, other co-maintainers, and the DBIC community at large to add their thoughts about the specifics of the plan or about the situation in general.

Given public and private discussions to date, we believe the DBIC community should consider questions such as:

How should the future governance of the DBIC project be decided?

Who should or shouldn't be involved in future governance?

Should the project be "frozen" or should development continue?

If "frozen", what specifically would a "freeze" entail? Would there be exceptions?

Re: IMPORTANT: A discussion of DBIC governance and future development

Regardless of what else happens, I very much would look forward to you finishing
up and shipping all the code changes you spent the last year working on. It
sounds like you're almost done them, and I don't want all that effort to go to
waste.

I trust you that this work would provide an island of stability of sorts, and a
version that people can continue to use for the extended term whether others
choose to just maintain that or choose to make major changes of their own, your
stable version would still be there as a useful legacy.

Given that your remaining time is limited, I request that you don't halt on the
code until the 8th as mentioned, unless you need to rest anyway, and use the
time you have to try and finish what you started and leave a better legacy.

Thank you for all your effort over the last years.

-- Darren Duncan

On 2016-10-03 2:32 PM, Peter Rabbitson wrote:

> On 10/03/2016 10:37 PM, David Golden wrote:
>>
>> <snip>
>>
>> In the ensuing discussion, Peter disclosed additional details about his
>> plans for the future of DBIC
>
> Given the discussion generated way more interest than I anticipated, at this
> point I am pausing all activity ( both code and administrative changes ), until
> at least the 8th of October. I want to give ample time for all interested
> parties to state their thoughts.
>
> From my side, in order to highlight the main "point of contention" if you will,
> I am pulling together several pieces from the aforementioned threads:
>
>> How much more concerning, then, to discover in the last few days
>> that you have seen your DBIC-related activities since December as
>> effectively winding up the project, rather than preparing to leave
>> it to others.
>> ...
>> I know a bunch of the the pending changes are not ready to merge (or
>> "sub-par" if you will); this is because I haven't had the motivation to
>> put more work into them
>> ...
>> I suspect if we managed to get all of the branches
>> people had planned that were delayed because riba's response to the proposed
>> features was "yes, but please wait for me to finish X first" done then that
>> work in itself might be a major release's worth.
>> ...
>> While I get that its (n.b. DBIC) depended on a fair bit, I don't think that
>> means being *perfect* to the exclusion of all experimentation. I don't think
>> I've come across other bits of CPAN, apart from maybe the ones in core, that
>> attempt to be as rigorous in their perfection. Really, if people upgrade,
>> and encounter an issue .. they can either downgrade and wait, or pitch in
>> and help (or pay someone to).. this is open source after all.
>
> While the project does not have a bright future under my (now likely moot) plan,
> the approach indicated above is, in my opinion, the worst possible direction,
> one I worked really hard to save this codebase from.
>
> Nevertheless, if nobody else finds this problematic: I will step aside and let
> an eager community, inadvertently suppressed all these years, steer this project
> further.
>
> Regards
> RIBASUSHI

Re: IMPORTANT: A discussion of DBIC governance and future development

RIBASUSHI has given this codebase a tremendous amount of care,
improvement, and deft effort. I am a user and evangelist of DBIC since
it was the first fork of CDBI that started to solve so many problems.
Peter has solved many problems since.

My view: MST must be respected but I personally defer to RIBASUSHI and
his judgement. I say, what he says, goes. He has earned the benefit of
the doubt. At least until it can be clearly demonstrated the approach
is harming the code base should that ever become the case.

> Peter,
>
> Regardless of what else happens, I very much would look forward to you
> finishing up and shipping all the code changes you spent the last year
> working on. It sounds like you're almost done them, and I don't want all
> that effort to go to waste.
>
> I trust you that this work would provide an island of stability of sorts,
> and a version that people can continue to use for the extended term whether
> others choose to just maintain that or choose to make major changes of their
> own, your stable version would still be there as a useful legacy.
>
> Given that your remaining time is limited, I request that you don't halt on
> the code until the 8th as mentioned, unless you need to rest anyway, and use
> the time you have to try and finish what you started and leave a better
> legacy.
>
> Thank you for all your effort over the last years.
>
> -- Darren Duncan
>
>
> On 2016-10-03 2:32 PM, Peter Rabbitson wrote:
>>
>> On 10/03/2016 10:37 PM, David Golden wrote:
>>>
>>>
>>> <snip>
>>>
>>> In the ensuing discussion, Peter disclosed additional details about his
>>> plans for the future of DBIC
>>
>>
>> Given the discussion generated way more interest than I anticipated, at
>> this
>> point I am pausing all activity ( both code and administrative changes ),
>> until
>> at least the 8th of October. I want to give ample time for all interested
>> parties to state their thoughts.
>>
>> From my side, in order to highlight the main "point of contention" if you
>> will,
>> I am pulling together several pieces from the aforementioned threads:
>>
>>> How much more concerning, then, to discover in the last few days
>>> that you have seen your DBIC-related activities since December as
>>> effectively winding up the project, rather than preparing to leave
>>> it to others.
>>> ...
>>> I know a bunch of the the pending changes are not ready to merge (or
>>> "sub-par" if you will); this is because I haven't had the motivation to
>>> put more work into them
>>> ...
>>> I suspect if we managed to get all of the branches
>>> people had planned that were delayed because riba's response to the
>>> proposed
>>> features was "yes, but please wait for me to finish X first" done then
>>> that
>>> work in itself might be a major release's worth.
>>> ...
>>> While I get that its (n.b. DBIC) depended on a fair bit, I don't think
>>> that
>>> means being *perfect* to the exclusion of all experimentation. I don't
>>> think
>>> I've come across other bits of CPAN, apart from maybe the ones in core,
>>> that
>>> attempt to be as rigorous in their perfection. Really, if people
>>> upgrade,
>>> and encounter an issue .. they can either downgrade and wait, or pitch
>>> in
>>> and help (or pay someone to).. this is open source after all.
>>
>>
>> While the project does not have a bright future under my (now likely moot)
>> plan,
>> the approach indicated above is, in my opinion, the worst possible
>> direction,
>> one I worked really hard to save this codebase from.
>>
>> Nevertheless, if nobody else finds this problematic: I will step aside and
>> let
>> an eager community, inadvertently suppressed all these years, steer this
>> project
>> further.
>>
>> Regards
>> RIBASUSHI
>
>
>
> _______________________________________________
> 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@...

Re: IMPORTANT: A discussion of DBIC governance and future development

>RIBASUSHI has given this codebase a tremendous amount of care,
>improvement, and deft effort. I am a user and evangelist of DBIC since
>it was the first fork of CDBI that started to solve so many problems.
>Peter has solved many problems since.
>
>My view: MST must be respected but I personally defer to RIBASUSHI and
>his judgement. I say, what he says, goes. He has earned the benefit of
>the doubt. At least until it can be clearly demonstrated the approach
>is harming the code base should that ever become the case.

+1, I could not have written this better.

Bye,

>
>­Ashley
>
>On Mon, Oct 3, 2016 at 6:09 PM, Darren Duncan <[hidden email]>
>wrote:
>> Peter,
>>
>> Regardless of what else happens, I very much would look forward to you
>> finishing up and shipping all the code changes you spent the last year
>> working on. It sounds like you're almost done them, and I don't want
>>all
>> that effort to go to waste.
>>
>> I trust you that this work would provide an island of stability of
>>sorts,
>> and a version that people can continue to use for the extended term
>>whether
>> others choose to just maintain that or choose to make major changes of
>>their
>> own, your stable version would still be there as a useful legacy.
>>
>> Given that your remaining time is limited, I request that you don't
>>halt on
>> the code until the 8th as mentioned, unless you need to rest anyway,
>>and use
>> the time you have to try and finish what you started and leave a better
>> legacy.
>>
>> Thank you for all your effort over the last years.
>>
>> -- Darren Duncan
>>
>>
>> On 2016-10-03 2:32 PM, Peter Rabbitson wrote:
>>>
>>> On 10/03/2016 10:37 PM, David Golden wrote:
>>>>
>>>>
>>>> <snip>
>>>>
>>>> In the ensuing discussion, Peter disclosed additional details about
>>>>his
>>>> plans for the future of DBIC
>>>
>>>
>>> Given the discussion generated way more interest than I anticipated, at
>>> this
>>> point I am pausing all activity ( both code and administrative changes
>>>),
>>> until
>>> at least the 8th of October. I want to give ample time for all
>>>interested
>>> parties to state their thoughts.
>>>
>>> From my side, in order to highlight the main "point of contention" if
>>>you
>>> will,
>>> I am pulling together several pieces from the aforementioned threads:
>>>
>>>> How much more concerning, then, to discover in the last few days
>>>> that you have seen your DBIC-related activities since December as
>>>> effectively winding up the project, rather than preparing to leave
>>>> it to others.
>>>> ...
>>>> I know a bunch of the the pending changes are not ready to merge (or
>>>> "sub-par" if you will); this is because I haven't had the motivation
>>>>to
>>>> put more work into them
>>>> ...
>>>> I suspect if we managed to get all of the branches
>>>> people had planned that were delayed because riba's response to the
>>>> proposed
>>>> features was "yes, but please wait for me to finish X first" done then
>>>> that
>>>> work in itself might be a major release's worth.
>>>> ...
>>>> While I get that its (n.b. DBIC) depended on a fair bit, I don't think
>>>> that
>>>> means being *perfect* to the exclusion of all experimentation. I
>>>>don't
>>>> think
>>>> I've come across other bits of CPAN, apart from maybe the ones in
>>>>core,
>>>> that
>>>> attempt to be as rigorous in their perfection. Really, if people
>>>> upgrade,
>>>> and encounter an issue .. they can either downgrade and wait, or
>>>>pitch
>>>> in
>>>> and help (or pay someone to).. this is open source after all.
>>>
>>>
>>> While the project does not have a bright future under my (now likely
>>>moot)
>>> plan,
>>> the approach indicated above is, in my opinion, the worst possible
>>> direction,
>>> one I worked really hard to save this codebase from.
>>>
>>> Nevertheless, if nobody else finds this problematic: I will step aside
>>>and
>>> let
>>> an eager community, inadvertently suppressed all these years, steer
>>>this
>>> project
>>> further.
>>>
>>> Regards
>>> RIBASUSHI
>>
>>
>>
>> _______________________________________________
>> 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@...>
>_______________________________________________
>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@...

Re: IMPORTANT: A discussion of DBIC governance and future development

On Tue, Oct 04, 2016 at 11:21:36AM +0100, Pedro Melo wrote:
> Hi,
>
> On 4/10/16 1:15 AM, "Ashley Pond V" <apv at sedition.com> wrote:
> >My view: MST must be respected but I personally defer to RIBASUSHI and
> >his judgement. I say, what he says, goes. He has earned the benefit of
> >the doubt. At least until it can be clearly demonstrated the approach
> >is harming the code base should that ever become the case.
>
> +1, I could not have written this better.

Given ribasushi's plan is "end all feature development because nobody else
can be trusted to add features without potentially introducing bugs", I'm
not sure how one could 'demonstrate harm' - freezing it and never adding
any features again is unlikely to *harm* the code base, merely kill the
project.

I mean, he's absolutely right that anybody else will, at this point,
be more likely to introduce bugs in the process of continuing development,
but if you read castaway's and ilmari's comments here:

that's at least partially because we've been effectively locked out of
contributing to the codebase for a couple years now, and all development
has been basically done without the discussion that would help us understand
the implementation as well as the goals.

I mean, if you genuinely believe ribasushi's right, and nobody else in the
world is competent to add features to DBIx::Class ever again, then fair
enough, let's start planning the funeral. But I can't see how that's the
best possible outcome here for the userbase as a whole.

Re: IMPORTANT: A discussion of DBIC governance and future development

I did say MST RFC:MUST be respected. :P This is only here because of
you. I was an early CDBI user and was there for the fights over its
direction and saw you as the voice of reason, patience, and vision.
Regardless of work done since, I see you as the owner. I was unaware
there was as much of a schism as there apparently is.

I don't know which approach is better. I feel the "permanent
development ban" you assert is misrepresenting the situation. I
haven't done any dev work here for years though so my opinion must be
heavily salted to be palatable. You speak of this situation killing
DBIC. I thought it was dying for a bit there a few years back and even
started exploring doing my own version. DBIC feels more vital now than
it had for quite some time. On the other hand, maybe it could
experience another renaissance if the gates reopen to more and easier
development.

So, I don't know. I do think it should be solved between lead devs
(past and present). There is apparently too much the peanut gallery
doesn't know and this is a practical not a theoretical discussion so
only those involved have truly valid opinions.

Re: IMPORTANT: A discussion of DBIC governance and future development

As I mentioned, I think it would be great to understand what Peter is thinking about a "freeze" – whether that's no new releases ever, or security/critical-bug-fix releases only, general bug fixes only, or something else.

I think it would be perfectly reasonable for people to say "we want stability more than new features, so yes to bug fixes, but no to new features".

I also think it would be perfectly reasonable for people to say they want new features, even if it risks introducing new bugs. And then people can debate how much risk to accept and what development processes might mitigate it.

Re: IMPORTANT: A discussion of DBIC governance and future development

On Tue, Oct 04, 2016 at 12:49:49PM -0400, Ashley Pond V wrote:
> I did say MST RFC:MUST be respected. :P This is only here because of
> you. I was an early CDBI user and was there for the fights over its
> direction and saw you as the voice of reason, patience, and vision.
> Regardless of work done since, I see you as the owner. I was unaware
> there was as much of a schism as there apparently is.
>
> I don't know which approach is better. I feel the "permanent
> development ban" you assert is misrepresenting the situation.

Well, I'm not sure how else I can interpret riba's call for a 'project
freeze', especially given that in

he appears to feel that the previous contributors attempting to continue
the project is "the worst possible direction, one I worked really hard to
save this codebase from."

Of course, it would help if he'd elaborate on his plan; so far, sadly,
he's expended a lot more words explaining why his future plans for
DBIx::Class aren't the contributors' or users' business than he has
explaining what said plans actually are. Hopefully that will change.

Re: IMPORTANT: A discussion of DBIC governance and future development

On 04/10/16 19:08, Matt S Trout wrote:

> On Tue, Oct 04, 2016 at 12:49:49PM -0400, Ashley Pond V wrote:
>> I did say MST RFC:MUST be respected. :P This is only here because of
>> you. I was an early CDBI user and was there for the fights over its
>> direction and saw you as the voice of reason, patience, and vision.
>> Regardless of work done since, I see you as the owner. I was unaware
>> there was as much of a schism as there apparently is.
>>
>> I don't know which approach is better. I feel the "permanent
>> development ban" you assert is misrepresenting the situation.
> Well, I'm not sure how else I can interpret riba's call for a 'project
> freeze', especially given that in
>
> http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/012210.html>
> he appears to feel that the previous contributors attempting to continue
> the project is "the worst possible direction, one I worked really hard to
> save this codebase from."

My reading is more that this:

/> Really, if people upgrade, />/and encounter an issue .. they can either downgrade and wait, or pitch in />/and help (or pay someone to).. this is open source after all./

is not a viable option if the breakage causes data loss. Problems at the
data layer are simply unacceptable and can result in major financial
damage and people being fired. Some projects can afford to be much more
bleeding edge but I feel that DBIx::Class needs to be paranoid about
what is accepted in core. After all there are other options to allow
features to be added without touching core.

DBIx::Class has gained a reputation for being a solid piece of
infrastructure which can be trusted and ribasushi has been instrumental
in getting it to that point. Care must be taken to ensure that this
expectation of reliability is not lost in favour of feature bloat and
risky code.

Re: IMPORTANT: A discussion of DBIC governance and future development

On Tue, Oct 04, 2016 at 08:20:51PM +0200, Peter Mottram wrote:

> On 04/10/16 19:08, Matt S Trout wrote:
> > On Tue, Oct 04, 2016 at 12:49:49PM -0400, Ashley Pond V wrote:
> >> I did say MST RFC:MUST be respected. :P This is only here because of
> >> you. I was an early CDBI user and was there for the fights over its
> >> direction and saw you as the voice of reason, patience, and vision.
> >> Regardless of work done since, I see you as the owner. I was unaware
> >> there was as much of a schism as there apparently is.
> >>
> >> I don't know which approach is better. I feel the "permanent
> >> development ban" you assert is misrepresenting the situation.
> > Well, I'm not sure how else I can interpret riba's call for a 'project
> > freeze', especially given that in
> >
> > http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/012210.html> >
> > he appears to feel that the previous contributors attempting to continue
> > the project is "the worst possible direction, one I worked really hard to
> > save this codebase from."
> My reading is more that this:
>
> /> Really, if people upgrade, />/and encounter an issue .. they can either downgrade and wait, or pitch in />/and help (or pay someone to).. this is open source after all./
>
> is not a viable option if the breakage causes data loss.

Please do remember that I'm the one who originally started a stable release
cycle, with vast attention to compatibility issues, because the idea of
damaging somebody's production data scares the crap out of me.

In fact, the only reason ribasushi became chainsaw delegate was because for
the first time I'd found somebody I trusted to be as worried about the
potential for data loss as I was.

> Some projects can afford to be much more
> bleeding edge but I feel that DBIx::Class needs to be paranoid about
> what is accepted in core. After all there are other options to allow
> features to be added without touching core.

The policy of DBIx::Class, as originally set by me, has always been that if
it can be done outside of core, it should be done outside of core.

I'm not sure what sort of cowboy future you're imagining but it certainly
isn't what any of the contributors signed up for, or what any of us have in
mind.

Re: IMPORTANT: A discussion of DBIC governance and future development

I'm only an occasional user of DBIx::Class. I don't use it for work. I do use it in my CMS Galileo (on CPAN) so I have some small standing I think. I also am interested in the governance situation generally as some of it may directly apply to another situation I'm in (more later).

First and foremost, I want to comment from the perspective of the outside user. I want to reiterate (as I think this thread has already established) that unlike what is asserted in http://www.nntp.perl.org/group/perl.modules/2016/10/msg96180.html the lack of people directly reaching out to ribasushi in regards to the handover of DBIC should not be construed as lack of concern on the part of the userbase. The problem as ever is the balance of feeling you have the standing to respond and feeling you have something to contribute. I imagine that there must be others who have had the thought "this does concern me, but I don't know what to say about it, it is certainly a hard question", as I have. In fact I'm not sure I have a whole lot more to say about this particular situation than that, other than the following:

I really don't think that any plan to transfer first-come to another person in secret is a great idea. Ribasushi has made it very clear the high position DBIC holds within the pantheon of CPAN distributions. I doubt Riba intends to pass it off to a malicious person, but in a worst case scenario, if that did happen, the handoff itself is essentially a security vulnerability. That is of course an alarmist response and I don't truly believe that to be the case. The tenor of this discussion DOES brook some concern though and I don't think outsiders looking in would be wrong to pin their dependencies at this very moment. We all know that most CPAN users don't (and indeed probably don't know how to) pin their dependencies, so it is always in the best interest of these "gems of CPAN" to hand over maintainership cleanly and openly. Again, I don't really have standing to vote in such a cause but please keep these kind of concerns in mind while this discussion continues.

---

On a slightly different note (as indicated before) there is a broader governance question, namely the one that caused mst to hand off first-come to Ribasushi in the first place. When it becomes expedient for a project founder to hand over maintainership to another person, the only mechanism to do it is to hand over first-come which essentially hands over all the rights to the distribution. This is partially the root cause of this dispute. I'm currently in a similar position wherein I would like to hand over day-to-day administration of Alien::Base to its de-facto maintainer Plicease. I haven't and will not do so because I still have strong opinions about Alien::Base even if I'm not doing most of the work of its development; Plicease is much more capable than I am in this area anyway.

That said I would like to see another level introduced into the PAUSE permissions system. For lack of a better name I would call it maintainer. Other people could hash out the specifics but generally it would be a role which has the permissions of the current first-come but yet be subject to the actual first-come (founder). I think had this level been available to mst, there would not now be any discussion about who has the final say, the project founder or the current first-come and major contributor. Further discussion of this matter should probably be a different thread however.

---

Finally, I would like to offer my one and only personal opinion on the matter at hand. Seeing the fact that DBIC was handed over to Ribasushi in an administrative capacity only, specifically with the assertion that mst wanted to retain rights to it is quite a twist to this story. Ribasushi has taken very good care of it to be sure, but to now turn around and assert that because of term of maintenance and number of commits/lines of code the code is now his own and the previous arrangement is void is troubling. Where is that line? Should mst have been informed when that line was crossed and asked if he wanted it back? Again, before I knew of the terms of the original handover I was inclined to side with Ribasushi as first-come holder. Now with the new information, I'm very torn. I know I would feel slighted if I had made a similar deal with someone to care for a project I had founded. Given the lack of administrative option available to mst, a handover with acknowledgement of retainer of rights was the only option. Again, another level of PAUSE perms might have averted all of this. In my perfect resolution of this, Ribasushi would live up to the original bargain.

I don't envy you David, this is a tough matter. I hope that an equitable solution can be reached.

On Tue, Oct 04, 2016 at 11:21:36AM +0100, Pedro Melo wrote:
> Hi,
>
> On 4/10/16 1:15 AM, "Ashley Pond V" <apv at sedition.com> wrote:
> >My view: MST must be respected but I personally defer to RIBASUSHI and
> >his judgement. I say, what he says, goes. He has earned the benefit of
> >the doubt. At least until it can be clearly demonstrated the approach
> >is harming the code base should that ever become the case.
>
> +1, I could not have written this better.

Given ribasushi's plan is "end all feature development because nobody else
can be trusted to add features without potentially introducing bugs", I'm
not sure how one could 'demonstrate harm' - freezing it and never adding
any features again is unlikely to *harm* the code base, merely kill the
project.

I mean, he's absolutely right that anybody else will, at this point,
be more likely to introduce bugs in the process of continuing development,
but if you read castaway's and ilmari's comments here:

that's at least partially because we've been effectively locked out of
contributing to the codebase for a couple years now, and all development
has been basically done without the discussion that would help us understand
the implementation as well as the goals.

I mean, if you genuinely believe ribasushi's right, and nobody else in the
world is competent to add features to DBIx::Class ever again, then fair
enough, let's start planning the funeral. But I can't see how that's the
best possible outcome here for the userbase as a whole.

Re: IMPORTANT: A discussion of DBIC governance and future development

Peter Mottram <[hidden email]> wrote:
> DBIx::Class has gained a reputation for being a solid piece of
> infrastructure which can be trusted and ribasushi has been instrumental
> in getting it to that point. Care must be taken to ensure that this
> expectation of reliability is not lost in favour of feature bloat and
> risky code.

I definitely agree that Riba's hard work to ensure reliability has
been extremely effective. But it's also the case that DBIC had an
impressive record of reliability long before he took over
maintainership, and I think we shouldn't lose sight of that simple
fact.

Nobody is suggesting that the project become a free-for-all of risky
features. But I do find it very difficult to see how we, the users of
DBIC, would be well served by the project being changed in a way that
bans all future changes other than trivial bug fixes — and that does
seem to be the model that's been proposed.

A slightly more concrete proposal

Since people seem to be unsure as to what the alternative to riba's project
freeze would actually be, let me provide something a little more concrete.

This is intended as a basis for discussion rather than a complete plan, but
I thought it was worth at least sketching a shape for things to come.

1) I think at this point we should formalise a core team. The BDFL model
was nice while it lasted, but I don't think it's tenable going forwards.

My first thought for composition would be a five-person team, and assuming
everybody agrees to it,that being Ilmari, Castaway (Jess Robinson), Frew,
myself, and whoever riba was planning to pass the first-come bits to.

That seems like it should be a nice combination of continuity and ensuring
that riba's fears we'll be insufficiently conservative being given a voice.

Exactly what would require a formal vote I leave as an open question for the
moment since it boils down to "what would leave both us and the userbase
comfortable things were being properly managed" and that'd require discussion.

2) I certainly wouldn't expect to be merging any clever branches any time
soon - understanding the work that riba did in private without discussion is
going to take time, since while his motivations were good the effect on us
is similar to the effect of taking over from a developer being territorial
in the name of job security - so keeping to careful bugfixes only for at
least the first six months is likely to be the only sensible approach.

3) New feature development will need to be approached carefully, and I
think we'll need to ensure we have a proper code review procedure in place
before merging things into master. Of course, public branches plus lots
of dev releases will also help, as will approaching this as an additive
process where as far as possible the existing logic remains untouched
until we're confident we understand what's going on where.

4) I still remember the fear induced adrenaline surge a little over a decade
ago when I realised that because I wasn't doing regular releases yet, people
were deploying svn trunk against their production database. That's how we got
a regular release cycle and a commitment to backcompat - I have, if anything,
always been more scared of data loss than the average of the user base, to
the point where I got threats from users to fork because we were being too
slow and conservative about adding features. I still believe in that, and
I think so do castaway/frew/ilmari.

5) I continue to believe that things that can be done outside of core should
be done outside of core, and that if at all possible we should prototype
APIs and feature sets in extensions first even if they'd be better served
being in core, but equally, if you look at the limitations of and the insane
code required in http://p3rl.org/DBIx::Class::ParamaterizedJoinHack you can
see that there are still things that core does not yet make as elegant and
robust as one might prefer, and I think it's worth at least trying to
improve on that.

Hopefully that gives people a clearer idea of what I think would end up
happening if we decide to move forwards once again as a team project.

Re: IMPORTANT: A discussion of DBIC governance and future development

> On Mon, 03 Oct 2016 23:32:18 +0200, rabbit+dbic at <rabbit.us> wrote:
>
>> Nevertheless, if nobody else finds this problematic: I will step aside
>> and let an eager community, inadvertently suppressed all these years,
>> steer this project further.
>
>
> Honestly, if anything i'd love to see a solution that offends everyone
> equally.
>
> You preparing your feature-frozen-bugfix-only release in a different
> namespace; mst's plan being used in the DBIx::Class namespace.
>
> That way people who're worried can stick to a stable branch of dbic, and
> people who actually need more from DBIc at some point in the future aren't
> lost in limbo.
>
> There's no need to deprive your stable-needing users of the work you had
> planned to do, nor your far future users of a useful library, if both can
> be served at the same time.

Re: A slightly more concrete proposal

Matt S Trout <[hidden email]> wrote:
> Since people seem to be unsure as to what the alternative to riba's project
> freeze would actually be, let me provide something a little more concrete.
>
> This is intended as a basis for discussion rather than a complete plan, but
> I thought it was worth at least sketching a shape for things to come.

<snip>

I like this proposal a lot. For one thing, having any concrete
proposal that can be discussed in detail is immensely valuable. As for
the specific content: this proposal seems to go a very long way to
ensuring that any concerns about stability can be met appropriately.

Re: IMPORTANT: A discussion of DBIC governance and future development

> On 4 October 2016 at 21:35, Christian Walde <[hidden email]> wrote:
> > On Mon, 03 Oct 2016 23:32:18 +0200, rabbit+dbic at <rabbit.us> wrote:
> >
> >> Nevertheless, if nobody else finds this problematic: I will step aside
> >> and let an eager community, inadvertently suppressed all these years,
> >> steer this project further.
> >
> >
> > Honestly, if anything i'd love to see a solution that offends everyone
> > equally.
> >
> > You preparing your feature-frozen-bugfix-only release in a different
> > namespace; mst's plan being used in the DBIx::Class namespace.
> >
> > That way people who're worried can stick to a stable branch of dbic, and
> > people who actually need more from DBIc at some point in the future aren't
> > lost in limbo.
> >
> > There's no need to deprive your stable-needing users of the work you had
> > planned to do, nor your far future users of a useful library, if both can
> > be served at the same time.
>
> +1

Note that we have prior technical art for providing bundled versions of
SQLA in dev releases which could absolutely be repurposed to allow for a
'use DBIx::Class::StabilityFreeze;' to work:

Re: A slightly more concrete proposal

I will also say that I intend to be a significant DBIC contributor personally
starting in the near future, estimated about 1 month from now. Initially that
will take the form of significant new core features developed in an experimental
branch, which can then be evaluated by other community members and the core team
for usefulness. If accepted these can then be selectively merged into core or
turned into extensions or inspire work by others as is best practice. While
large changes are anticipated as fruit, they are by design intended to be fully
backwards-compatible with regular user code.

-- Darren Duncan

On 2016-10-04 1:17 PM, Matt S Trout wrote:

> Since people seem to be unsure as to what the alternative to riba's project
> freeze would actually be, let me provide something a little more concrete.
>
> This is intended as a basis for discussion rather than a complete plan, but
> I thought it was worth at least sketching a shape for things to come.
>
> 1) I think at this point we should formalise a core team. The BDFL model
> was nice while it lasted, but I don't think it's tenable going forwards.
>
> My first thought for composition would be a five-person team, and assuming
> everybody agrees to it,that being Ilmari, Castaway (Jess Robinson), Frew,
> myself, and whoever riba was planning to pass the first-come bits to.
>
> That seems like it should be a nice combination of continuity and ensuring
> that riba's fears we'll be insufficiently conservative being given a voice.
>
> Exactly what would require a formal vote I leave as an open question for the
> moment since it boils down to "what would leave both us and the userbase
> comfortable things were being properly managed" and that'd require discussion.
>
> 2) I certainly wouldn't expect to be merging any clever branches any time
> soon - understanding the work that riba did in private without discussion is
> going to take time, since while his motivations were good the effect on us
> is similar to the effect of taking over from a developer being territorial
> in the name of job security - so keeping to careful bugfixes only for at
> least the first six months is likely to be the only sensible approach.
>
> 3) New feature development will need to be approached carefully, and I
> think we'll need to ensure we have a proper code review procedure in place
> before merging things into master. Of course, public branches plus lots
> of dev releases will also help, as will approaching this as an additive
> process where as far as possible the existing logic remains untouched
> until we're confident we understand what's going on where.
>
> 4) I still remember the fear induced adrenaline surge a little over a decade
> ago when I realised that because I wasn't doing regular releases yet, people
> were deploying svn trunk against their production database. That's how we got
> a regular release cycle and a commitment to backcompat - I have, if anything,
> always been more scared of data loss than the average of the user base, to
> the point where I got threats from users to fork because we were being too
> slow and conservative about adding features. I still believe in that, and
> I think so do castaway/frew/ilmari.
>
> 5) I continue to believe that things that can be done outside of core should
> be done outside of core, and that if at all possible we should prototype
> APIs and feature sets in extensions first even if they'd be better served
> being in core, but equally, if you look at the limitations of and the insane
> code required in http://p3rl.org/DBIx::Class::ParamaterizedJoinHack you can
> see that there are still things that core does not yet make as elegant and
> robust as one might prefer, and I think it's worth at least trying to
> improve on that.
>
> Hopefully that gives people a clearer idea of what I think would end up
> happening if we decide to move forwards once again as a team project.
>