[Dbix-class] 2/5 Where I saw (and where I hope) the project going

[Peter Rabbitson]

On 10/07/2016 08:40 PM, David Golden wrote:
>
> In particular, whether part of the plan or not, I think the community
> would benefit from hearing more detail on your thoughts for what a
> stable "freeze" would look like – what kinds of things should be allowed
> or not allowed to change, how to do QA, etc.

As I already mentioned in the "1/5 ..." email, what I was speaking of 
was an API freeze. This does not mean "no new features ever", instead it 
means "only features with no obvious downsides / obvious half-baked 
status". I do not see how could we possibly expend huge amount of energy 
on /usr/bin/perl remaining coherent across the board, yet be so eager to 
accept introduction and deletion of experiments in CPAN "crown jewels".

On what should and should not be allowed: if there was a way for me to 
distill this kind of "common sense" into a flowchart, we would not be 
having this conversation. The general rule of thumb is that "whatever 
can be done outside should be done outside". DBIC is a ridiculously 
flexible framework. And during my ownership of the project I stopped at 
nothing to preserve and enhance this flexibility. The calls to start 
merging ::Helpers and other pieces back into the DBIC core seem at best 
misguided to me, given the original point of the project was to be an 
"ORM building toolkit". Combined with the obvious deficiencies of parts 
of the core already (the entire ::Row/::RsrcProxy subsystem is a joke, 
as described in [1]), I quite frankly do not understand where many of 
the "moar features" and "moar API surface" voices in this thread are 
coming from.

It is true that *some* features require internal work to take place. 
This kind of internal work must be weighted against the risk to the 
existing user-base (to which user-base the project is forever beholden, 
first and foremost).

This kind of work also can not happen on a schedule, nor can it fall 
prey to "consensus", nor can be led by an "enthusiast" developer. As 
long as it remains in the same widely-used namespace, it can only be 
ready when it is ready, and nothing short of "the best we can do based 
on our state of the art knowledge".

As an example here is the evolution of the new (hopefully) upcoming 
resolve_relationship_condition() public method:

https://github.com/dbsrgits/dbix-class/commit/03f6d1f7b
https://github.com/dbsrgits/dbix-class/commit/a446d7f8f
https://github.com/dbsrgits/dbix-class/commit/1adbd3fc4
https://github.com/dbsrgits/dbix-class/commit/c2abfbbeb
https://github.com/dbsrgits/dbix-class/commit/5592d6332
https://github.com/dbsrgits/dbix-class/commit/83a6b2443
https://github.com/dbsrgits/dbix-class/commit/209a20649
https://github.com/dbsrgits/dbix-class/commit/350e8d57b
https://github.com/dbsrgits/dbix-class/commit/c19ca6e80
https://github.com/dbsrgits/dbix-class/commit/7cb7914bc
https://github.com/dbsrgits/dbix-class/commit/98def3efb
https://github.com/dbsrgits/dbix-class/commit/e884e5d9d
https://github.com/dbsrgits/dbix-class/commit/7967dcecd
https://github.com/dbsrgits/dbix-class/commit/c0f445097
https://github.com/dbsrgits/dbix-class/commit/e65228c03
https://github.com/dbsrgits/dbix-class/commit/7e5a0e7c2
https://github.com/dbsrgits/dbix-class/commit/7df2b5df3
https://github.com/dbsrgits/dbix-class/commit/21621fe45
https://github.com/dbsrgits/dbix-class/commit/c200d9497
https://github.com/dbsrgits/dbix-class/commit/e084cb2bc
https://github.com/dbsrgits/dbix-class/commit/4f8c96780
https://github.com/dbsrgits/dbix-class/commit/65abdb857
https://github.com/dbsrgits/dbix-class/commit/de54e8bd6
https://github.com/dbsrgits/dbix-class/commit/d8516e922
https://github.com/dbsrgits/dbix-class/commit/3aac91f35
https://github.com/dbsrgits/dbix-class/commit/786c1cdde
https://github.com/dbsrgits/dbix-class/commit/ea3ee77d2
https://github.com/dbsrgits/dbix-class/commit/a3ae79ed1
https://github.com/dbsrgits/dbix-class/commit/86be9bcb9
https://github.com/dbsrgits/dbix-class/commit/1bd54f3d4
https://github.com/dbsrgits/dbix-class/commit/e5c638290
https://github.com/dbsrgits/dbix-class/commit/7293955e1

The above is a *single* method being developed over ~2 years, with only 
the final commit being an invitation for others to "please try to use 
this thing". All of the changes were made based on self-feedback due to 
dogfooding and on smoking downstreams and performing some alpha-testing 
with select darkpan codebases.

This is the price of cohesion.

I strongly believe the attitudes of the 200x-era "throw it on CPAN and 
iterate until users stop complaining" are no longer an option today.

I hope that whoever (hopefully single person) takes the reins will 
continue this vision of not turning the project into an npm-distributed 
systemd-implementation.

> Particularly if there is a
> possibility of the namespace branching into "stable" and "ongoing
> development" parts (regardless of which side stays "DBIx::Class"), I
> think your views on how the stable branch ought to be managed would be
> valuable insight to whoever winds up managing it.

There is always a possibility. You (David) yourself advocated exactly 
this 6 month ago [2] for another project that subsequently drove off a 
cliff under very similar circumstances.

On whether one such "stable branch" would be needed: it would be strange 
for me to be educating the PAUSE admins on the fact that forks and 
index-pins do not work within the current CPAN infrastructure. You guys 
already know all of this, and what is at stake.

On how such a branch would be managed - I do not have a simple answer to 
this question. However see my other replies.

[1] 
https://blog.afoolishmanifesto.com/posts/open-source-infrastructure-and-dbix-class-diagnostics-improvements/#background:50782e73c9797a6438b7d24dbf6c56b7
[2] 
http://blogs.perl.org/users/chad_exodist_granum/2016/04/test2testbuilder-update-from-the-qah.html#comment-1702913