IMPORTANT: A discussion of DBIC governance and future development

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
119 messages Options
123456
Reply | Threaded
Open this post in threaded view
|

Re: A slightly more concrete proposal

David Golden
On Sat, Oct 8, 2016 at 5:33 PM, Peter Rabbitson <[hidden email]> wrote:
>> Given that Peter abdicated the right to choose first-come himself
>
> This is not the case. The right was taken away from me, in an unprecedented
> overreach by the PAUSE admins, as summarized by Graham Knop in
> http://www.nntp.perl.org/group/perl.modules/2016/10/msg96217.html

I will repeat the language previously used: a unilateral transfer was
unacceptable.

I can understand how Peter might interpret that as a "right taken
away".  However, management of a namespace is not a right.  It is a
privilege delegated by PAUSE administrators to CPAN authors following
certain rules and historical conventions.  (Quite literally, it is
permission to modify certain database tables in PAUSE.)

Further, Peter's prior agreement with Matt at the time of the initial
transfer calls into question whether Peter can, in fact, claim an
exclusive, unilateral privilege to name a successor.

If there is something unprecedented in this situation, it is Peter's
agreement to – and subsequent repudiation of – a permissions transfer
agreement that included a "takeback" clause.

Given Peter's claim that his subsequent work gives him moral authority
to repudiate the agreement, we believe that the community is in the
best position to assess such a claim and ultimately to guide the
future of DBIC.  We are pleased with the engagement to date.

Peter certainly is allowed to propose a successor (either his original
choice or an alternative) and we have repeatedly encouraged him to do
so.  Peter is also an important figure in the project and his voice
should be valued in the selection of new governance and a roadmap for
the future.

If he chooses not to name a successor or participate in discussions
for personal reasons, that is up to him and we encourage people to
respect his boundaries.

Regards,
David

_______________________________________________
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@...
Reply | Threaded
Open this post in threaded view
|

1/5 What is stability

Peter Rabbitson-2
In reply to this post by David Golden
On 10/07/2016 08:40 PM, David Golden wrote:
>
>> * As a final point on "going forward": I am concerned that the "software
>> stability" argument has been grossly micharacterized[sic]: it was presented
>> as a binary "does it lose data" argument, when for me the main question has
>> always been "is it opinionated / does it insist on usurping the end-users
>> time".
>
> I think this would be a wonderful topic for you to elaborate on.
>

Before answering "what is stable" it is worth noting what is the purpose
of the software we provide (in this case on CPAN). Using my own words
from a private conversation:

> I would think that a software platform should optimize for folks to consistently being able to leave the office at a reasonable time instead of manufacturing calamities every N units of time "in order to stay relevant"

It is a commonly held belief in open source that us providing our labor
for free exempts us from the responsibility to respect the time and
labor of the people we build for. This belief is embarrassingly
misguided. Accepting this would be akin to accepting a volunteer
firefighter packing up their gear and going home when things quite
literally get too hot.

To drive this even closer home I encourage all participants of these
threads to see the first 8 minutes of another presentation by Aral
Balkan[1]. These first 8 minutes are a brilliant unscheduled impromptu
commentary on the frantic attempts of the conference organizers to get a
failed projector working. If 8 minutes is too much time to spare here is
a small transcribed excerpt from this improv:

> ...So experiences matter. And the reason that we have to focus on building
> things that don't just "work", especially don't just "work for us", but are
> great experiences for other people: is not because we want to show off, not
> because we want to be seen as rockstars. But because we respect peoples
> experiences, we respect, fundamentally, their lives.
> And I think this (n.b. presentation hardware failure) is a beautiful way of
> making that point, so I am really glad that the projector is not working, I
> don't know about you.
> (n.b. in response to a staff member) Heh, it's "working" but it's "not
> connecting". Ok: great! See: that's great to know, but for someone sitting in
> the audience it's just not working. It could be not working for many amazing
> reasons. For things that are very interesting, that maybe we could write a
> paper on. But for you sitting in those seats: it's just not working. And it's
> the same with software and with the things that we build: if something doesn't
> work we'd love to take it apart and find out why. But for someone who needs
> that to work for them to do what they need to do: it just doesn't work. And we
> need to start building things that "just work".

So back to "what is stable" when applied to a library: quite simply it
is reduction of churn experienced by the end user. This in no way means
"no new features ever", but instead means planning things ahead with the
full understanding what are the consequences of ones actions if they
were to fail.

To put it differently here is me again from about a year ago[2]:

> I believe that if an end-user (corporate and individual alike) needs to change
> their application code upon library upgrade, while the changes do not offer
> compelling direct benefits to their codebase - this is a sign I have failed
> as a maintainer, and it is on me to find a better way, and make things right
> for the user.

CPAN has a very long history of well-, and not-so-well- maintained
libraries. It is very rare for almost anything to just "cause data
loss". Additionally these are the really simple cases: they are
discovered and fixed almost instantly.

It is the subtle changes deep down in an dependency stack that have been
made without regard to "what sits on top", that are the real problem.
These changes take a long time to propagate to their victims, and take
even longer time (if at all) to traverse the feedback loop back to the
authors. For a much better and in-depth (albeit somewhat tangential)
writeup about this, please consider reading [3].


Words are well and good, but what does this actually mean in practice?
In retrospect "freeze" was an unfortunate choice of words, which got
hijacked in the subsequent threads to mean "stagnation" or even
inexplicably "death of the project". What I really meant was "API
freeze", which has already been the case for quite some time as far as
this project is concerned.

Instead of trying to explain this in prose let me illustrate this in
numbers since the time I got back to DBIC at the end of 2012:

~/devel/dbic$ git log --reverse -p -C -w -U0 v0.082840 ^v0.08203 lib \
| grep -Po '^[+-]sub (?!_)\S+' \
| sort -s -t ' ' -k2 \
| grep '^-' -A1 \
| grep -v -- '^--' \
| wc -l

Places the count of ~4 years of events for non-private methods being
moved around at 48.

Even if we add in the not-yet-released *fully backwards compatible*
overhaul of callchains 1cf609901 [4]:

~/devel/dbic$ git log --reverse -p -C -w -U0 dc7d89911 ^v0.08203 lib \
| grep -Po '^[+-]sub (?!_)\S+' \
| sort -s -t ' ' -k2 \
| grep '^-' -A1 \
| grep -v -- '^--' \
| wc -l

we end up with 196.

As a comparison let's examine another popular perl framework during the
same time period:

~/devel/moose$ git log --reverse -p -C -w -U0 2.1806 ^2.0600 lib \
| grep -Po '^[+-]sub (?!_)\S+' \
| sort -s -t ' ' -k2 \
| grep '^-' -A1 \
| grep -v -- '^--' \
| wc -l

This comes back at 76.

And another:

~/devel/mojolicious$ git log --reverse -p -C -w -U0 v7.08 ^v3.48 lib \
| grep -Po '^[+-]sub (?!_)\S+' \
| sort -s -t ' ' -k2 \
| grep '^-' -A1 \
| grep -v -- '^--' \
| wc -l

This comes back with 1135.


The above is by no means a robust measurement - it is obviously a
heuristic. However it demonstrates in practical terms what "stability"
actually means. To take a (rare on CPAN) example of an end-user App look
at the end of commit message 12e7015a [5]: in order to be able to run
the test suite of Expense::Tracker[6] I have to downgrade Mojolicious
back more than 250(!) releases. And once I do that the application
works, and passes its tests. So as far as Expense::Tracker - what is the
benefit here? In the end it simply "doesn't work".


This is the kind of churn I have been trying to avoid with DBIC, and
which was my #1 job (and is arguably the job of any responsible
maintainer). Not churning out new features, but steadfastly saying "no"
to things with questionable cost/benefit ratios.

I do not feel great about the fact that I had to turn people's code
away, but I remain unapologetic: the code that has not yet merged is
simply not yet good enough.


Excellence should not be negotiable.


[1] https://youtu.be/A23Xoa5CE7g?t=35
[2]
https://gist.github.com/ribasushi/d3769fa75822b7b080e9#file-tilt_description-L197-L201
[3] https://eev.ee/blog/2016/02/10/we-have-always-been-at-war-with-ui/
[4]
https://blog.afoolishmanifesto.com/posts/open-source-infrastructure-and-dbix-class-diagnostics-improvements/
[5] https://github.com/dbsrgits/dbix-class/commit/12e7015a
[6] https://metacpan.org/release/Expense-Tracker

_______________________________________________
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@...
Reply | Threaded
Open this post in threaded view
|

2/5 Where I saw (and where I hope) the project going

Peter Rabbitson-2
In reply to this post by David Golden
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@...
Reply | Threaded
Open this post in threaded view
|

2/5 Where I saw (and where I hope) the project going

Peter Rabbitson-2
In reply to this post by David Golden
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@...
Reply | Threaded
Open this post in threaded view
|

Let's call things what they are 1/2

Peter Rabbitson-2
In reply to this post by David Golden
On 10/09/2016 06:35 AM, David Golden wrote:
>
> Further, Peter's prior agreement with Matt at the time of the initial
> transfer calls into question whether Peter can, in fact, claim an
> exclusive, unilateral privilege to name a successor.

David, to use your own language from [hidden email][1]:

     > Saying it repeatedly will not make it true.

I presented ample evidence to supports my claim, culminating with the
following exchange[2] on 2015-12-07 (which *was* also mentioned in [3]):

> mst_20151207.log:[16:42:22] <mst> aight. what stuff are you going to want me to take on?
> mst_20151207.log:[18:06:39] <ribasushi> um... we talked about this - I am not doing an orderly handover
> mst_20151207.log:[18:06:45] <ribasushi> so.. nothing? :)
> mst_20151207.log:[18:07:03] <ribasushi> am going to be @ LPW, can talk more then if you insist
> mst_20151208.log:[15:54:23] <mst> you said on the blog post you'll be transferring maint bits. I'm not asking for orderly, just a heads up as to which things I'm going to wake up on boxing day owning, if anyway
> mst_20151208.log:[16:39:12] <ribasushi> that bridge will be burning when I get to it
> mst_20151208.log:[16:39:12] <ribasushi> don't worry - I will not land you in a Scwern-like situation
> mst_20151208.log:[16:39:12] <ribasushi> but that's about it
> mst_20151208.log:[16:44:55] <mst> so, basically "giving warning would stop it being the not-orderly thing you have in mind, but while you're trying to make a splash, you're going to do so without causing carnage" or so?
> mst_20151208.log:[16:45:31] <ribasushi> I promise you no carnage.
> mst_20151208.log:[16:51:07] <mst> right, well, fair enough. I can't really ask anything more, even if I would dearly -like- to ask for more, if you see what I mean :)
> mst_20151208.log:[16:56:23] <ribasushi> I do.

The *entirety* of the work performed since then was undertaken under my
being misled into thinking Matt recognized and acknowledged that he can
not be a part of DBIx::Class' future.

In other words, to make it as clear as possible: the PAUSE admins'
taking a side in mst's 11th-hour scramble for relevance placed in limbo
the following:

~/devel/dbic$ git diff -C -w --shortstat 6a0bca69f dc7d89911
    516 files changed, 13941 insertions(+), 4547 deletions(-)

Could we please recognize the situation and its consequences for what
they are?

[1] http://www.nntp.perl.org/group/perl.modules/2016/10/msg96181.html
[2] https://gist.github.com/ribasushi/f2502a29f5e2c7c48e03f7bd34e7ddd2
[3] http://www.nntp.perl.org/group/perl.modules/2016/10/msg96174.html

_______________________________________________
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@...
Reply | Threaded
Open this post in threaded view
|

3/5 Why my plan got scrapped

Peter Rabbitson-2
In reply to this post by David Golden
On 10/07/2016 08:40 PM, David Golden wrote:

>>
>> * The plan of succession I formed in December 2015, and had not
>> deviated from until this week, is presently null and void. It was
>> an unusual arrangement, with critical pieces based on a combination
>> of promises and assumptions. Recent events resulted in the invalidation
>> of several such foundation points, and there is no possible way I myself
>> could presently endorse it.
>
> I find this very vague and would appreciate any additional information
> you feel you can share.  I'm disappointed that we (both the community
> and the PAUSE admins, in this context) never got to hear more details
> about your plan than what I quoted in my original email of this thread.
>

The plan got scrapped for 2 main reasons:

1) It was my understanding[1] that Matt recognized and accepted his
irrelevance to the project[2], and was not going to interfere with it
going forward (see next email "4/5..." on why this is crucial)

2) I gravely misjudged how far the user community drifted from the
unanimous endorsement[3] 3 years ago of the following (I quote):

> Would DBIx::Class benefit more from my continued, albeit somewhat
> abrasive, presence at the helm (which implies continuous rejection
> of "worse is better", slow and careful "ready when ready"-style
> release cycles, multiple layers of checks and testing, and generally
> slow vetting and acceptance of external contributions)?

The person I was going to hand an *exclusive* FIRSTCOME to, would be
among other things relying on a steadfast, demanding and uncompromising
user community to keep them honest. The threads demonstrated that this
community of users no longer exists (or perhaps they are silent, which
in the end would have the same effect).

[1] http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/012279.html
[2] https://gist.github.com/ribasushi/f2502a29f5e2c7c48e03f7bd34e7ddd2
[3]
http://blogs.perl.org/users/peter_rabbitson/2013/07/crowdsourcing-self-confidence.html#comments

_______________________________________________
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@...
Reply | Threaded
Open this post in threaded view
|

4/5 Why Matt's proposal is a farce

Peter Rabbitson-2
In reply to this post by David Golden
On 10/07/2016 08:40 PM, David Golden wrote:

>>
>> [...] I have grave reservations about the specific (now) 4-member team
>> outlined by Matt. The reservations are entirely technical and procedural
>> in nature [...] I will elaborate on these reservations if necessary
>
> As above, I think hearing your reservations and the rationale behind
> them would be valuable input.  It's clear from the comments from the
> community so far that stability (however defined) is important to many.
> Your thoughts on what would and wouldn't work will help shape the
> discussion of future governance.

Words are cheap. Let's look at the record instead: In the past several
years mst has been directly responsible ( single-handedly or in part )
for the following:

- Shoving FATAL-ized warnings down CPAN's users throats. After years of
incessant pushback finally semi-relented[1], but still continues to
insert it into his CPAN projects to this day.

- Advocated for the insertion of a computed goto[2] into the core of
Dancer2's routing dispatch[3], making it inherently unsafe, with
currently little hope for a fix.

- Advocated for proliferation of Module::Build::Tiny, under the banner
of "we need to keep trying new things", leading to massive levels of
inconvenience/wasted time for both packagers and end-users.

- Was pivotal in ramming through the questionable ( to say the least )
changes in the Test::More namespace, under the banner of "we are going
to try and find out"[4], knowing full well there is no rolling back from
this action.

- Is currently salivating to yet again attempt to rewrite
SQL::Abstract[5], despite clear signs that this is a bad plan[6] (mst
himself seemed to agree with [6] around 2016-05-17)


In order to "balance out" his "enthusiast"[7] tendencies (if this is
even possible given mst's personality) Matt proposes:


- ilmari: Decidedly another "ehthusiast". Great at proposing and
implementing low-hanging-fruit fixups. Yet loses interest whenever the
problem space required a more in-depth solution.

- castaway: Openly decries DBIC[8] for being unlike "... other
bits of CPAN, apart from maybe the ones in core, that attempt to be as
rigorous in their perfection"

- frew: True, the only person in the entire thread so far to echo my
understanding of "stability"[9]. Has a very mature approach to software
engineering, and while having "enthusiast" leanings as well is able to
recognize when it is time to put his tools down. On the down-side: has
(understandably) no patience for pesky squabbles, and has expressed
unambiguously his involvement won't be "what it used to be"[10]

So in a sense we have the illusion of a committee, and the result will
yet again be experiments at the expense of the user base, under a
supposedly-well-meaning pretext similar to [4].


Many participants of these threads were very quick to declare "the BDFL
model does not work". This despite the fact that virtually all coherent
software in the CPAN ecosystem (including /usr/bin/perl itself) are a
product of this very model.


Matt promises a better and more careful way going forward. At the same
time none of his more recent high-profile actions have even the remote
indication of some sort of maturity beyond his 2005-era mindset. For
crying out loud: we are talking about the person who considers this Rube
Goldberg machine[11] fit for every day use!!!


This is why I remain utterly skeptical. As they say (in Texas I think):
Fool me 5 times in a row...


[1] http://shadow.cat/blog/matt-s-trout/moo-2-strictures-2/
[2]
https://metacpan.org/source/MAUKE/Return-MultiLevel-0.04/lib/Return/MultiLevel.pm#L95
[3] https://github.com/PerlDancer/Dancer2/issues/1125#issuecomment-179326519
[4]
http://blogs.perl.org/users/chad_exodist_granum/2016/04/test2testbuilder-update-from-the-qah.html#comment-1702921
[5] https://irclog.perlgeek.de/perl6/2016-09-23#i_13264359
[6]
https://github.com/dbsrgits/dbix-class/commit/07fadea8d#diff-b1e08875e88f9cfd4c48251700469d84R90
[7] https://youtu.be/A23Xoa5CE7g?t=2363
[8] http://www.nntp.perl.org/group/perl.modules/2016/10/msg96192.html
[9] http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/012277.html
[10] http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/012254.html
[11] https://youtu.be/j3r-lKlrrRg?t=1035

_______________________________________________
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@...
Reply | Threaded
Open this post in threaded view
|

5/5 Why "a stability tzar" is a ridiculous proposition

Peter Rabbitson-2
In reply to this post by David Golden
On 10/07/2016 08:40 PM, David Golden wrote:
>
>> [...] I do not think it would be right for me to try to be the
>> captain that steers us out of this mess.
>
> Understood.  As I've said before, if there are people inside or outside
> the community that you think could continue to represent the "extreme
> stability" point of view as part of future project governance, I think
> it would benefit the community for you to see if they are interested in
> such a role and to nominate/endorse them as a voice you respect in that way.

I believe that characterizing the direction of this project in the past
~4 years as "extreme stability" is extremely(ha!) unfair and misleading.
What I did was borderline common sense. What *maybe* sets me aside is
that I was able to devote more time to this goal, but that's about it.

Additionally stability on its own isn't tangible, nor does it yield a
final product. It is simply a mindset. When this mindset is not
represented in the group as a whole, it makes no difference whatsoever
whether a small part of said group is advocating it or not. My train of
thought should be familiar to you, I wrote the same when making my
(clearly failed) push for saner CPAN practices[1]:

> This is not a simple feel-good undertaking, it does require a lot of buy-in, and the buy-in has to come from within, from your own agreement that the current status quo is unworkable going forward.

I currently do not know anyone within or outside the community who is
both driven by a strong "inner core" of sensible priorities *AND* would
be remotely interested in continuous sparing with mst over whether it is
ok to experiment on the wider userbase.

[1]
https://gist.github.com/ribasushi/74ce356123ede727e90f#file-2015-01-31-md

_______________________________________________
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@...
Reply | Threaded
Open this post in threaded view
|

Let's call things what they are 2/2

Peter Rabbitson-2
In reply to this post by Matt S Trout-2
On 10/08/2016 04:07 PM, Matt S Trout wrote:

>
> (4) Same statement as 3, but with an added point: You don't need to have me
> back either. Frew's right that I can be kind of an asshole (hell, one of
> the reasons I wanted him on this team was because he has a knack for making
> me realise I've done it again in time to do something about it), and I've
> been mostly gone for a fair few years, and I don't have a concrete vision
> here because I was rather expecting riba to do something more sensible than
> this so I didn't expect to need one. But I'm happy to try (and there's no
> need to reply to fluff my ego if you -are- ok with tolerating me again, I
> just don't feel like people whispering 'takeover' later).
>

To make it as clear as possible, and protect what I wrote so far from
mis-interpretation:

Given the long-established goals/priorities of this namespace, and mst's
*technical* track record [1], it is my immutable opinion that
DBIx::Class has no future as long as Matt Trout has any privileged (i.e.
not a mere user) influence on DBIC's governance and direction.

This is also why I am not granting Daren Duncan's request[2]. It makes
no sense to do anything until there is unambiguous *lasting* clarity wrt
the above.

[1] http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/012282.html
[2] http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/012269.html

_______________________________________________
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@...
Reply | Threaded
Open this post in threaded view
|

Re: Let's call things what they are 1/2

David Golden
In reply to this post by Peter Rabbitson-2
On Tue, Oct 11, 2016 at 1:23 PM, Peter Rabbitson <[hidden email]> wrote:
On 10/09/2016 06:35 AM, David Golden wrote:

Further, Peter's prior agreement with Matt at the time of the initial
transfer calls into question whether Peter can, in fact, claim an
exclusive, unilateral privilege to name a successor.

David, to use your own language from [hidden email][1]:

    > Saying it repeatedly will not make it true.


Note: "calls into question" means there is an unresolved question.  You may believe there is no question, but the consensus of PAUSE administrators is that there is.  This is true by construction.  As soon as we wonder what the right outcome is, the question has been called.

Specifically, we didn't think this situation was clear cut for *either* side, which is why we wanted discussion among affected parties to inform the outcome rather than deciding peremptorily in favor of either party in the dispute.
 
I presented ample evidence to supports my claim, culminating with the following exchange[2] on 2015-12-07 (which *was* also mentioned in [3]):

[snip]
mst_20151208.log:[16:44:55] <mst> so, basically "giving warning would stop it being the not-orderly thing you have in mind, but while you're trying to make a splash, you're going to do so without causing carnage" or so?
mst_20151208.log:[16:45:31] <ribasushi> I promise you no carnage.

Speaking personally, I read that entire exchange in the context of your post about leaving CPAN entirely and thus about *all* your modules, not DBIC specifically.  Again, speaking personally, I consider kicking out all co-maintainers a form of "carnage".  So I don't see in that exchange any sort of prior approval for the course of action you appear to have intended.

I think it's unfortunate that you didn't feel you could be more open about your intentions earlier as much misunderstanding would have been avoided.
 
In other words, to make it as clear as possible: the PAUSE admins' taking a side in mst's 11th-hour scramble for relevance placed in limbo the following:

~/devel/dbic$ git diff -C -w --shortstat 6a0bca69f dc7d89911
   516 files changed, 13941 insertions(+), 4547 deletions(-)


That sounds like a threat.  Is that what you intended?

Regards,
David

--
David Golden <[hidden email]> Twitter/IRC/GitHub: @xdg

_______________________________________________
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@...
Reply | Threaded
Open this post in threaded view
|

Re: Let's call things what they are 1/2

Peter Rabbitson-2
On 10/11/2016 07:51 PM, David Golden wrote:

> On Tue, Oct 11, 2016 at 1:23 PM, Peter Rabbitson <[hidden email]
>
>     In other words, to make it as clear as possible: the PAUSE admins'
>     taking a side in mst's 11th-hour scramble for relevance placed in
>     limbo the following:
>
>     ~/devel/dbic$ git diff -C -w --shortstat 6a0bca69f dc7d89911
>        516 files changed, 13941 insertions(+), 4547 deletions(-)
>
>
> That sounds like a threat.  Is that what you intended?
>

No, it is a PSA.

I currently do not see a clear mechanism by which this effort could now
reach the CPAN index.

I myself can no longer ship this myself ( as explained previously ), and
I have reasons to believe that this work will be scrapped by the "new
management".

I am simply highlighting the uncertainty currently in place.


_______________________________________________
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@...
Reply | Threaded
Open this post in threaded view
|

Re: Let's call things what they are 2/2

Darren Duncan
In reply to this post by Peter Rabbitson-2
On 2016-10-11 10:30 AM, Peter Rabbitson wrote:

> To make it as clear as possible, and protect what I wrote so far from
> mis-interpretation:
>
> Given the long-established goals/priorities of this namespace, and mst's
> *technical* track record [1], it is my immutable opinion that DBIx::Class has no
> future as long as Matt Trout has any privileged (i.e. not a mere user) influence
> on DBIC's governance and direction.
>
> This is also why I am not granting Daren Duncan's request[2]. It makes no sense
> to do anything until there is unambiguous *lasting* clarity wrt the above.
>
> [1] http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/012282.html
> [2] http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/012269.html

So the only good reason I can think of to not more effectively give the DBIC
users the fruits of your labor to date, by (simply?) cutting a CPAN release, is
that you are concerned that said changes as is might break something for users
that currently works, and then someone with the desired stability mindset won't
be around to deal with fixing that in a timely manner.

Whereas, if I am wrong and the primary reason against releasing your existing
work isn't about the risk of breaking things for users, then I don't understand
why the future DBIC governance has any bearing on what you can do right now.

If you could clarify that, I would appreciate it.

Regardless, I agree with what you said in "1/5 What is stability" and thank you
for all your work over the years.

-- Darren Duncan


_______________________________________________
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@...
Reply | Threaded
Open this post in threaded view
|

Re: Let's call things what they are 2/2

Matt S Trout-2
On Tue, Oct 11, 2016 at 11:55:42AM -0700, Darren Duncan wrote:
> Whereas, if I am wrong and the primary reason against releasing your
> existing work isn't about the risk of breaking things for users,
> then I don't understand why the future DBIC governance has any
> bearing on what you can do right now.

Right now, I still consider riba to be chainsaw delegate on technical
matters, and he has every right to complete and ship this work if he
believes that to be the best thing for the code and user base.

> Regardless, I agree with what you said in "1/5 What is stability"

The thing is ... mostly, so do I, and in general, over the years, the vast
majority of stability arguments that he and I have been involved in have been
ones where both of us have been on the same side - fighting for more attention
to be paid to stability than people seemed to be intending to - and it's
been really nice to have the company.

The examples given of my being against stability are, well, the most visible
times we've disagreed. But at least up until a couple of years ago, my
memory says we've been on the same side a lot more often than not.

Where we diverge is where you get to -

https://twitter.com/ribasushi/status/727539149822132224

'There is "general FOSS" and there is "platform FOSS" In face of
uncertainty In the latter case the imperative is to do nothing'

which I agree is a good *default*, but not always universally correct.

Some times something is a big enough leap forwards that it justifies taking
the risk of shipping it and having to clean up a few small fires that ensue
as a result. To pick an example dear to my heart, we went through six
dev releases before shipping 0.05 (and had enough people using DBIC against
their production database that I was already moderately paranoid), but
then still had to do a couple of releases very quickly afterwards to fix
bugs people found.

On the other hand, that release is when ResultSet acquired a search() method
and became chainable.

So, basically: from where I'm standing I hold 90% of riba's stance to be
self evident, but prefer to be utilitarian rather than dogmatic about the
remaining cases.

I'd hope that the combination of a core team and a public decision making
process that consults the userbase about priorities will be sufficient to
ensure that if people thinking I'm weighting said utility function wrongly,
I'll find out before applying the results.

--
Matt S Trout - Shadowcat Systems - Perl consulting with a commit bit and a clue

http://shadowcat.co.uk/blog/matt-s-trout/   http://twitter.com/shadowcat_mst/

Email me now on mst (at) shadowcat.co.uk and let's chat about how our CPAN
commercial support, training and consultancy packages could help your team.

_______________________________________________
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@...
Reply | Threaded
Open this post in threaded view
|

Re: 5/5 Why "a stability tzar" is a ridiculous proposition

Aristotle Pagaltzis
In reply to this post by Peter Rabbitson-2
* Peter Rabbitson <[hidden email]> [2016-10-11 17:28]:
> Additionally stability on its own isn't tangible, nor does it yield
> a final product. It is simply a mindset. When this mindset is not
> represented in the group as a whole, it makes no difference whatsoever
> whether a small part of said group is advocating it or not.

This might be easier to explain by analogy to a hypothetical notion of
a “security czar” in a project where all the active contributors treat
security as a check list item somewhere in the medium-priority section
of their personal list. I assume it to be fairly obvious to all by now
why appointing such a security czar will lead to no real improvements
in the security of that project.

And to reiterate the analogy in another area where this principle might
be somewhat widely recognized nowadays, in order to show that neither
stability nor security are special snowflakes: the same is true of
product design in teams that treat design as something you sprinkle on
after most of the work is done. Having a design czar won’t yield much
improvement in design for the end user. (Free software has demonstrated
this regrettably clearly and consistently…)

A sidecar can’t steer the vehicle.

The position of a czar is reactive and disempowered. They can only fire-
fight individual issues as the project hurtles forward headlong.

If you want real security or actual good design, it must be part of the
culture: it must pervade every choice, every judgement call. Otherwise
you get zilch, or maybe a veneer. Just the same is true of stability, or
any other similar value.

(And in fact, any time a whatever-czar is appointed I would worry that
the presence of such a role will tempt the rest of the team to slack off
in their own consideration of the faux-delegated concern. If the role of
that person is a mentor rather than a czar – then that is an arrangement
which might work. But it requires willingness of every other team member
to actually be mentored and carry that concern personally, as opposed to
e.g. considering the project to be trying too hard to be secure or well-
designed, relative to everyone else in the same ecosystem.)

Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>

_______________________________________________
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@...
Reply | Threaded
Open this post in threaded view
|

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

Alexander Hartmaier
In reply to this post by Darren Duncan
On 2016-10-06 21:15, Darren Duncan wrote:

> On 2016-10-06 8:43 AM, Matt S Trout wrote:
>> On Tue, Oct 04, 2016 at 08:17:49PM -0700, Darren Duncan wrote:
>>> That would be good, also in light with how that sentence continues:
>>>
>>> "I suspect what we need to try and achieve is to get DBIC a bit more
>>> decentralised - have it be a specific framework build atop a
>>> more-like-Plack-for-DB-stuff - but you already know that's what I
>>> have in mind and we both already know it's going to be a big-ass job
>>> and we'll see if it pans out or not."
>>>
>>> My own near term planned contributions to DBIC are precisely what
>>> you said above.  They would constitute a more-like-Plack-for-DB
>>> ecosystem and in particular they should benefit DBIC by optimizing
>>> it more for maintainability, so it is easier for others to add
>>> features or make changes or otherwise just be more confident that it
>>> works properly.  If things go as I hope, this should start to land
>>> in about a month.
>>
>> I think anything that's in that sort of vicinity is likely to be a big
>> enough set of changes that it'll (a) need to wait until whatever new
>> administration we end up with is settled in (b) need a decent RFC
>> process
>> and advance discussion of the risk/reward trade-offs involved.
>>
>> After all, when I say "big-ass job" I'm generally not kidding about
>> that,
>> and at this point it looks like it's not only going to be a big-ass job,
>> but a big-ass job we're going to have to conduct without the help of the
>> person I was relying on being the other half of the architecture team
>> for
>> it.
>>
>> So, I mean, "cool" but also "this is going to need serious
>> discussion" and
>> especially "please don't get your hopes up about 'near term'".
>
> Not to worry, and I agree.
>
> The first version of the thing that I was intending to land in the
> short term was only intended to be, on its own, classified as a green
> field experiment or proof of concept.  It would NOT by any means be
> intended for production as is.
>
> Basically I am working on a Plack-for-DB as an independent project,
> and I was going to use an experimental fork of DBIC (on GitHub) as an
> initial test case by roughly replacing DBIC guts to use that project
> while using the fact that DBIC's pristine automated test suite as a
> validation that DBIC still behaves correctly with the changed internals.
>
> The new administration of DBIC can then use this working proof of
> concept in their discussions on how they want to formally evolve
> DBIC.  My experiment would constitute an RFC for how would you like to
> use my Plack-for-DB, or adapt its design, to implement DBIC features
> that were long desired but not provided.
>
> -- Darren Duncan
Isn't DBI 'Plack-for-DB'?
>
>
> _______________________________________________
> 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@...



*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
Notice: This e-mail contains information that is confidential and may be privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*

_______________________________________________
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@...
Reply | Threaded
Open this post in threaded view
|

Re: Let's call things what they are 2/2

Peter Rabbitson-2
In reply to this post by Darren Duncan
On 10/11/2016 08:55 PM, Darren Duncan wrote:
>
> So the only good reason I can think of to not more effectively give the
> DBIC users the fruits of your labor to date, by (simply?) cutting a CPAN
> release, is that you are concerned that said changes as is might break
> something for users that currently works, and then someone with the
> desired stability mindset won't be around to deal with fixing that in a
> timely manner.

Sigh... let me make it as clear as possible:

- I consider the current tip of the dbsrgits repo[1] safe to use in
production. It has already been successfully tested against a massive
amount of downstream deps[2], and is being used in several select
darkpan outfits.

- The work was undertaken in a manner making it virtually impossible for
silent/latent (not instantly obvious) breakage to creep in.

- Breakage itself is always a risk, and can not be 100% avoided. I have
applied everything in my toolbox to mitigate the potential, but it is
still there: it would be silly to claim otherwise.

- I *will* be available to fix currently unknown problems in a timely
manner. In case the code is taken forward by someone, I will be
available for an indefinite period of time to answer questions, and in
some limited cases to produce fixes to whatever is uncovered in the
process of wider use. Such support will be carried out either on this
mailing list or via the already-existing publicly logged(!) support
channel[3]. For the foreseeable future I will continue to be available
during a pre-defined "office hours" window, currently at Mon-Fri
15:00~16:30 UTC. My longer term involvement is also somewhat guaranteed
by the fact of my $paying_job being a DBIx::Class user, thus I have a
vested interest in the codebase not driving off a cliff (though this
interest is in the role of a user, not former codebase owner).

- Given the new realities of the future of this namespace (all of which
I was not aware of until [4]), I can not proceed with my original plan
as stated multiple times in this thread. Doing otherwise ( by further
committing to the repository and/or shipping stuff to CPAN under a
group-controlled namespace ) would imply tacit endorsement of the
currently presented proposal for the project governance. I will not do that.

>
> Whereas, if I am wrong and the primary reason against releasing your
> existing work isn't about the risk of breaking things for users, then I
> don't understand why the future DBIC governance has any bearing on what
> you can do right now.
>

The link between *future* governance and *current* code is everything.
The current and future attitudes within CPAN as a whole is the very
reason I am distancing myself from various pieces I have been ( I
believe positively ) involved in.

It is like asking me why I am suddenly heading to the nearest exit half
way through preparing the dessert of a 10 course meal on board of what I
thought is the RMS Olympic, once I am most casually informed that we are
in fact on board her sister-ship.

Darren, you are correct - there is no *direct* provable link between
what is now and what is tomorrow. On the other hand being pretty good at
extrapolating and evaluating potential outcomes is what makes us human
in the first place. Forgive me for being one.

[1] https://github.com/dbsrgits/dbix-class/commit/dc7d8991
[2] https://github.com/dbsrgits/dbix-class/commit/12e7015a
[3] https://irclog.perlgeek.de/askriba/2016-10-12#i_13382567
[4] http://www.nntp.perl.org/group/perl.modules/2016/09/msg96139.html

_______________________________________________
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@...
Reply | Threaded
Open this post in threaded view
|

Re: 4/5 Why Matt's proposal is a farce

David Cantrell
In reply to this post by Peter Rabbitson-2
On Tue, Oct 11, 2016 at 07:27:03PM +0200, Peter Rabbitson wrote:

> Words are cheap. Let's look at the record instead: In the past several
> years mst has been directly responsible ( single-handedly or in part )
> for the following:
>
> - Shoving FATAL-ized warnings down CPAN's users throats. After years of
> incessant pushback finally semi-relented[1], but still continues to
> insert it into his CPAN projects to this day.

This is not necessarily a bad thing.

In fact I've done it myself. First I deprecated a feature in the
documentation. Then a while later I made it emit a warning. Then another
while later I got rid of it which, if people were still using the
deprecated feature, made their code die. Getting rid of the deprecated
features made the code simpler and easier to understand, and so less
likely to be a bug-laden piece of crap.

And this is software whose users *must* keep it up to date for it to be
useful. Unlike with DBIx::Class, whose users can quite happily keep
using an old version if they don't want new features, users of
Number::Phone will get wrong results if they don't keep up to date. And
those wrong results will cost them money, because they're using it to do
things like bill their customers and route phone calls.

--
David Cantrell | Nth greatest programmer in the world

You can't spell "slaughter" without "laughter"

_______________________________________________
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@...
Reply | Threaded
Open this post in threaded view
|

Re: 5/5 Why "a stability tzar" is a ridiculous proposition

David Golden
In reply to this post by Aristotle Pagaltzis
On Wed, Oct 12, 2016 at 2:54 AM, Aristotle Pagaltzis <[hidden email]> wrote:
The position of a czar is reactive and disempowered. They can only fire-
fight individual issues as the project hurtles forward headlong.

If you want real security or actual good design, it must be part of the
culture: it must pervade every choice, every judgement call. Otherwise
you get zilch, or maybe a veneer. Just the same is true of stability, or
any other similar value.


Speaking personally again, I beg to differ.  During the 2008 financial crisis, when most banks were losing money, Goldman Sachs made money.  Why?

One major reason was that the bank's risk management function was listened to and heeded.  All traders constantly *think about* risk, but they do so in the context of tradeoffs in local decisions. Is the reward worth the risk for this investment?  Only the risk management function looked at the aggregate risk of the bank as a whole and judged whether there was "too much" risk.  When risk management said "cut down those positions" or "hedge that exposure", GS traders did what they said.  Other banks treated risk management like Cassandra in the myths.  As the CEO of Citibank put it "as long as the music is playing, you've got to dance."

The same could be true of a software project.  Developers could be assessing risk vs reward tradeoffs locally.  Is *this* PR worth it?  Will *this* refactoring break too much stuff?  There could well be a role for stability oversight that looks at the aggregate whole and says "STOP".  But it only works if heeded by the rest – if the group trusts the oversight enough to delegate the power to decide when it's too much.

Does it need to be a single person?  Could it be a team responsibility like a Toyota-style "Stop the Line" button? I think a community can decide how it wants to mechanically run a stop process.

The important thing – if stability is truly important – is making sure that people with the right perspectives on aggregate stability are known, involved, and heeded.

David

--
David Golden <[hidden email]> Twitter/IRC/GitHub: @xdg

_______________________________________________
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@...
Reply | Threaded
Open this post in threaded view
|

Re: 5/5 Why "a stability tzar" is a ridiculous proposition

Colin Newell
>
> Does it need to be a single person?  Could it be a team responsibility like
> a Toyota-style "Stop the Line" button? I think a community can decide how it
> wants to mechanically run a stop process.
>
> The important thing – if stability is truly important – is making sure that
> people with the right perspectives on aggregate stability are known,
> involved, and heeded.
>
> David
>

I think it might be worth going back to frew's suggestion of the
Collective Code Construction Contract and think about whether we can
try to adopt the risk management into the general governance of the
project.  We all seem to agree on what stability we want.  We are
mostly arguing over how we achieve it.

I would like it to be easy enough that a developer new to the project,
without needing to get deep in irc communication or mailing lists, can
contribute a feature/improvement with a reasonable expectation of it
being accepted.  That's actually relatively rare with most open source
projects, but I don't see why it needs to be.  If there is clear
documentation regarding what is acceptable from a stability point of
view, how to contact people when you want to ask questions or for
opionions, and explaining what level of tests are required it is quite
possible that they will be able to produce a reasonable change without
much assistance.  By having the documented process it should also make
it easier for the reviewers to complain about stability breaking
things without needing to worry too much about how to put it, as the
documentation should have the words.

If we have good core guidelines then the people should mater less, and
it should be easier to encourage other people to chip in time to do
reviews and  help with running the project, rather than it simply
being seen as a fight.  Having good people is definitely something we
need, but we should consider that they may not be available all the
time forever.  Hopefully having things written down will help.


Colin.

_______________________________________________
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@...
Reply | Threaded
Open this post in threaded view
|

Re: 4/5 Why Matt's proposal is a farce

Jess Robinson
In reply to this post by Peter Rabbitson-2
On Tue, 11 Oct 2016 18:27:03 +0100, Peter Rabbitson  
<[hidden email]> wrote:

> On 10/07/2016 08:40 PM, David Golden wrote:
>>>
>>> [...] I have grave reservations about the specific (now) 4-member team
>>> outlined by Matt. The reservations are entirely technical and  
>>> procedural
>>> in nature [...] I will elaborate on these reservations if necessary
>>
>> As above, I think hearing your reservations and the rationale behind
>> them would be valuable input.  It's clear from the comments from the
>> community so far that stability (however defined) is important to many.
>> Your thoughts on what would and wouldn't work will help shape the
>> discussion of future governance.
>
>
> - ilmari: Decidedly another "ehthusiast". Great at proposing and  
> implementing low-hanging-fruit fixups. Yet loses interest whenever the  
> problem space required a more in-depth solution.
>
> - castaway: Openly decries DBIC[8] for being unlike "... other
> bits of CPAN, apart from maybe the ones in core, that attempt to be as
> rigorous in their perfection"
>
> - frew: True, the only person in the entire thread so far to echo my  
> understanding of "stability"[9]. Has a very mature approach to software  
> engineering, and while having "enthusiast" leanings as well is able to  
> recognize when it is time to put his tools down. On the down-side: has  
> (understandably) no patience for pesky squabbles, and has expressed  
> unambiguously his involvement won't be "what it used to be"[10]
>

.. If anyone wonders why I've been quiet, this may help explain it... This  
is difficult to reply to, so this is as much as you're going to get.

Jess


_______________________________________________
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@...
123456