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
_______________________________________________
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
