Re: [Dbix-class] GOVERNANCE: Aggregation and conclusion

[Matt S Trout]

On Wed, Nov 02, 2016 at 06:08:39PM -0600, Darin McBride wrote:
> Yes, we see JSON, JSON::XS, JSON::PP all with a single JSON interface, and 
> magic happening under the covers. However, because, in theory, all of these 
> will provide *exactly the same functionality* and interfaces, only a 
> performance difference, that's fine.  Since the goal of DBIC / DBIC2 is to 
> diverge,

Or the goal could be to have a compatible superset of DBIC's APIs, or it
could be to do something CDICompat style, or ...

If you want to know what the goals would be, first you need to find somebody
who's planning such a fork and ask them, surely.

Otherwise, this conversation seems to basically just be a cheese shop sketch.

-- 
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@lists.scsys.co.uk

Re: [Dbix-class] GOVERNANCE: Aggregation and conclusion

[Darin McBride]

On Wednesday November 2 2016 11:38:35 PM Matt S Trout wrote:
> On Wed, Nov 02, 2016 at 04:32:31PM -0600, Darin McBride wrote:
> > On Monday October 31 2016 11:22:07 AM Andrew Beverley wrote:
> > > On Mon, 31 Oct 2016 00:43:31 Matt S Trout  wrote:
> > > > Otherwise, I would suggest that you turn your plan into a full
> > > > proposal,
> > > 
> > > TBH, I didn't even realise I was making a proposal until I saw the
> > > results[1]. I was merely bringing up one of Dave's earlier
> > > suggestions[2], which several others also seemed to like.
> > > 
> > > But, in that case, I propose:
> > > 
> > > - RIBASUSHI retains the current namespace, continuing to maintain and
> > > tighten that code base. The aim would be a rock-solid module with a
> > > very conservative rate of change and new features.
> > > 
> > > - A new namespace DBIx::Class2 is created, owned and operated by MST's
> > > governance+core team proposal. Developers that want to create new
> > > features do so in this namespace.
> > > 
> > > I do not understand the technicalities, but from what I have seen
> > > discussed, people would still be able to use DBIx::Class::* modules in
> > > both namespaces.
> > 
> > There is one piece missing, IMO.  The rest of CPAN.  Maybe there's a
> > simple
> > solution, maybe this is a non-issue.  But, not knowing the internals of
> > DBIC plugins, I'm going to ask the dumb questions.
> > 
> > 
> > As a user of DBIC, let's say I want to go with the "dangerous" DBIC2
> > instead of the stable DBIC.  It has some feature I really want that just
> > got released next year some time.  However, I have a bunch of DBIx::Class
> > plugins as well. Do the plugins Just Work (TM) with DBIC2 despite the
> > namespace change? Obviously, my own code needs to derive off a new set of
> > base classes, which I sort of asked for by virtue of switching.  Ideally,
> > that'd be it - but is it?
> Actually, I think it can potentially be done without needing to force people
> to s{}{} their superclass lines, but only given active co-operation between
> the people developing both.

Yes, we see JSON, JSON::XS, JSON::PP all with a single JSON interface, and 
magic happening under the covers. However, because, in theory, all of these 
will provide *exactly the same functionality* and interfaces, only a 
performance difference, that's fine.  Since the goal of DBIC / DBIC2 is to 
diverge, I don't think I'd want to see them "automatically" work for the end 
user.  There should, IMO, be some level of action required by the end user to 
say "I want DBIC2."  Otherwise there is literally no reason for forking.  Even 
if it were "use DBI::Class 2;" (which, obviously, would require active co-
operation, but doesn't really gain us anything over "use DBI::Class2;")

I'm more thinking of the Mo/Moo/Mouse/Moose compatibility, where, with the 
right incantations in plugins/other modules, they can work with any of the 
above, and the application developer at the end can choose which one to use.  
At least some plugins can, obviously plugins that require the heavier feature 
set of Moose won't work with Moo, and that's okay.

Anyway, my question is more pointed at how broken, or not, the rest of the 
DBIx::Class namespace would be in a DBIC2 application, especially one that was 
working with DBIC and wants to convert to DBIC2.  If much carnage is expected, 
then that would affect the voting, I imagine.  Or maybe I'm alone on this.

(I think it is obvious that many applications won't convert, and that's fine, I 
would hope and expect no breakage there through any "conversion" process 
here.)

> Any other approach will, I think, inevitably result in the same sort of
> troubles the Dancer/Dancer2 split caused (I argued for managing to maintain
> sufficiently backwards compatibility in the new codebase to not require the
> split; I lost).
> 
> Given I think it's fairly clear at this point that "active co-operation" is
> unlikely to describe the relationship between riba and I going forwards, I
> hope this explains why I don't consider myself suitable to be involved in
> a fork.


___
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

Re: [Dbix-class] GOVERNANCE: Aggregation and conclusion

[Matt S Trout]

On Wed, Nov 02, 2016 at 04:32:31PM -0600, Darin McBride wrote:
> On Monday October 31 2016 11:22:07 AM Andrew Beverley wrote:
> > On Mon, 31 Oct 2016 00:43:31 Matt S Trout  wrote:
> > > Otherwise, I would suggest that you turn your plan into a full
> > > proposal,
> > 
> > TBH, I didn't even realise I was making a proposal until I saw the
> > results[1]. I was merely bringing up one of Dave's earlier
> > suggestions[2], which several others also seemed to like.
> > 
> > But, in that case, I propose:
> > 
> > - RIBASUSHI retains the current namespace, continuing to maintain and
> > tighten that code base. The aim would be a rock-solid module with a
> > very conservative rate of change and new features.
> > 
> > - A new namespace DBIx::Class2 is created, owned and operated by MST's
> > governance+core team proposal. Developers that want to create new
> > features do so in this namespace.
> > 
> > I do not understand the technicalities, but from what I have seen
> > discussed, people would still be able to use DBIx::Class::* modules in
> > both namespaces.
> 
> There is one piece missing, IMO.  The rest of CPAN.  Maybe there's a simple 
> solution, maybe this is a non-issue.  But, not knowing the internals of DBIC 
> plugins, I'm going to ask the dumb questions.
> 
> 
> As a user of DBIC, let's say I want to go with the "dangerous" DBIC2 instead 
> of the stable DBIC.  It has some feature I really want that just got released 
> next year some time.  However, I have a bunch of DBIx::Class plugins as well. 
>  
> Do the plugins Just Work (TM) with DBIC2 despite the namespace change?  
> Obviously, my own code needs to derive off a new set of base classes, which I 
> sort of asked for by virtue of switching.  Ideally, that'd be it - but is it?

Actually, I think it can potentially be done without needing to force people
to s{}{} their superclass lines, but only given active co-operation between
the people developing both.

Any other approach will, I think, inevitably result in the same sort of
troubles the Dancer/Dancer2 split caused (I argued for managing to maintain
sufficiently backwards compatibility in the new codebase to not require the
split; I lost).

Given I think it's fairly clear at this point that "active co-operation" is
unlikely to describe the relationship between riba and I going forwards, I
hope this explains why I don't consider myself suitable to be involved in
a fork.

-- 
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@lists.scsys.co.uk

Re: [Dbix-class] The email I didn't want to write.

[Matt S Trout]

On Wed, Nov 02, 2016 at 11:50:24AM +0100, Peter Rabbitson wrote:
> On 11/01/2016 11:18 PM, Matt S Trout wrote:
> >
> >...
> >
> >This seems like a surprising description of ilmari, given he holds the
> >first-come permissions for both DBIx::Class::Schema::Loader and SQL::Abstract
> 
> PAUSE disagrees:
> 
> rabbit@Ahasver:~$ curl -s
> http://cpan.metacpan.org/modules/06perms.txt.gz | zgrep
> '^SQL::Abstract,.*,f$'
> SQL::Abstract,MSTROUT,f

Ah, my mistake. Of course, given your treatment of and attitude towards
me, my point is if anything rather stronger in that case.
 
> >and conducted a huge and highly successful refactor of the former.
> 
> True, ilmari did work on S::L recently, but let's give credit where
> credit is due:

I was talking about during his first stint as DBICSL primary maintainer.

And, of course, given the entire point of refactoring is to make it easier
to maintain and extend a codebase, the fact that a number of people
successfully did so afterwards should rather be expected if the refactoring
were highly successful.
 
> >
> >...
> >
> >Meanwhile, we've now reached a point where seeing a ticket or patch sent in
> >by ribasushi tends to result in people ignoring it for a few days because
> >they need to work up the emotional stoicism required to deal with the chances
> >of it being a useful patch/ticket that happens to come with a free polemic.
> 
> Citation needed. Please provide an example where I have been abusive
> or even slightly unprofessional in a bugreport. Issue trackers are
> generally always part of the public record, so it shouldn't be a
> problem to back up what was said above.

I could go back and find somebody mentioning being made to feel like that
and to then cross-reference to the ticket, but that would require outing
them as having said so and given your general treatment of disagreement in
this thread I'm not convinced that's fair. People may choose to disregard
this assertion on my part as a result if they so wish.

But let me ask you a slightly different question, phrased relatively openly
to avoid prejudicing your answer - why do you no longer discuss issues on
perl5-porters?
 
> Matt, with all said above - can you please clarify:
> 
> >- who's actively attacked and/or alienated the owners of many of our 
> >downstream
> >  dependencies, including the crucial SQL::Abstract

Well, y'know, I came here for a governance discussion and honestly I'm
feeling pretty attacked right now.

"rabid badger"
"elephant in the room"
"enthusiast"
unfounded accusations of abuse of IRC OPER rights, quietly retracted without
an apology for the error

And, of course, we're rather dependent on SQL::Translator too and castaway
bowed out of this discussion some time back to avoid being attacked further.

My apologies for the single factual innacuracy; please consider that this
conversation might go more constructively if you were to ask me what I
meant about questions rather than simply assert that I'm wrong.

-- 
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@lists.scsys.co.uk

Re: [Dbix-class] GOVERNANCE: Aggregation and conclusion

[Darin McBride]

On Monday October 31 2016 11:22:07 AM Andrew Beverley wrote:
> On Mon, 31 Oct 2016 00:43:31 Matt S Trout  wrote:
> > Otherwise, I would suggest that you turn your plan into a full
> > proposal,
> 
> TBH, I didn't even realise I was making a proposal until I saw the
> results[1]. I was merely bringing up one of Dave's earlier
> suggestions[2], which several others also seemed to like.
> 
> But, in that case, I propose:
> 
> - RIBASUSHI retains the current namespace, continuing to maintain and
> tighten that code base. The aim would be a rock-solid module with a
> very conservative rate of change and new features.
> 
> - A new namespace DBIx::Class2 is created, owned and operated by MST's
> governance+core team proposal. Developers that want to create new
> features do so in this namespace.
> 
> I do not understand the technicalities, but from what I have seen
> discussed, people would still be able to use DBIx::Class::* modules in
> both namespaces.

There is one piece missing, IMO.  The rest of CPAN.  Maybe there's a simple 
solution, maybe this is a non-issue.  But, not knowing the internals of DBIC 
plugins, I'm going to ask the dumb questions.


As a user of DBIC, let's say I want to go with the "dangerous" DBIC2 instead 
of the stable DBIC.  It has some feature I really want that just got released 
next year some time.  However, I have a bunch of DBIx::Class plugins as well.  
Do the plugins Just Work (TM) with DBIC2 despite the namespace change?  
Obviously, my own code needs to derive off a new set of base classes, which I 
sort of asked for by virtue of switching.  Ideally, that'd be it - but is it?

If other DBIC modules that exist on CPAN need updating to work with DBIC2 
(presumably, they could work against both DBIC and DBIC2), what updating is 
it?  What can DBIC2 do to minimise this?

Presumably, some plugins out there are "stable" already and their authors may 
have already abandoned them, more or less, is this split going to be a make-
work project, with much angst and gnashing of teeth just to get all the 
plugins various DBIC2 users are using updated on CPAN?

If changes need to be made, is there something reasonable that an end-user who 
switches can do to monkey-patch things so that DBIC plugins will work with 
DBIC2?

Is DBIC2 going to be able to co-exist with DBIC?  Not merely on CPAN, but also 
on a user's perl installation?  I'm presuming this would be the plan, but I do 
want to ask.

I think this information would greatly impact my ability to vote.  Basically, 
how broken is someone if they go with the very first DBIC2 release?  If it will 
take 2 or 3 years from the first DBIC2 release until the ecosystem supports it 
well enough to make it viable for end-users to switch, I would think the split 
would then be basically DOA - it would be entirely moot.  On the other hand, 
if there is a list of 5 or fewer steps that users would need to do to start 
work with it, including all plugins (e.g., "in your code, switch this use 
statement to that, and call this monkey-patch function against your plugins"), 
it would tighten the feedback loop to at least make it viable.  Further, if 
there is a nice cargo-cult-style chunk of code that plugins can use to auto-
select between DBIC and DBIC2 support, right from that first release, it would 
greatly aid in the transition speed.  If, however, no plugin can support both 
DBIC and DBIC2 simultaneously without duplicating code or other code smells, 
then we would want to really think carefully about advocating a split.  I just 
don't know.


I think a secondary set of questions are also in need of asking, though final 
decisions on these likely can be deferred to consensus should the split be 
approved.  Questions such as whether fixes found in DBIC2 that also affect DBIC 
would be offered, whether as patches or pull requests or whatever format riba 
would want them in, back to DBIC as a matter of default policy (this does not 
tie riba's hands to actually accept them).  And, if riba doesn't accept them 
as is but fixes the same problem in another way, would that be merged back to 
DBIC2?  Another question here would be whether DBIC updates in general would 
be merged into DBIC2.  Having default positions on these from the "split" 
side, should it exist, would show priorities as well as indicate whether votes 
need to be taken, i.e., if the reverse from the default were being proposed.


___
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

Re: [Dbix-class] GOVERNANCE: Aggregation and conclusion

[Darren Duncan]

On 2016-11-02 3:53 AM, Peter Rabbitson wrote:

On 10/31/2016 02:40 PM, Peter Rabbitson wrote:

Same here (wrt not wanting to re-live this situation again). I will
respond to the above points around midnight UTC ( ~11h from now ).


Apologies for my silence. The combination of a time-zone shift with an unusually
early day-start leaves me way less "productive time" than I anticipated. I will
publish a to-the-point workable proposal by the end of this week.

Stay tuned.


Peter, I don't know your plan, but I think it would be very important if your 
own proposal included authorizing a team itself, where you name several 
individuals that you trust, and they have PAUSE/etc rights from the start.


The idea here is that even for people who trust you as a benevolent dictator 
with control of PAUSE/etc rights, there is still the problem of bus number 
equals 1 if your proposal had you being the only one with those rights. 
Supporters of your proposal would still want to know that if something happens 
to you, others are in the position to govern.


You had already named some people you were more likely to trust would share your 
values, and the mysterious successor, so surely there are names for this.


Thank you.

-- 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@lists.scsys.co.uk

Re: [Dbix-class] GOVERNANCE: Aggregation and conclusion

[Wallace Reis]

On November 2, 2016 at 7:02:46 AM, Dave Cross (d...@dave.org.uk) wrote:
> > Mee too.
> 
> +1 Matt's proposal (new project team)
> -1 Andrew's proposal (forking)

+1 (new project team)
-1 (forking)

--
Wallace Reis

___
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

Re: [Dbix-class] GOVERNANCE: Aggregation and conclusion

[Stefan Hornburg (Racke)]

On 11/02/2016 10:11 AM, Stefan Hornburg (Racke) wrote:
> On 11/02/2016 10:07 AM, Paul Mooney wrote:
>> On 02.11.2016 09:02, Dave Cross wrote:
>>> Quoting Matthias Zeichmann :
>>>
 On Tue, Nov 1, 2016 at 10:45 PM, Charlie Garrison 
 wrote:

> On 1 Nov 2016, at 19:48, Thomas Klausner wrote:
>
>> I think a fork will not work. The "old" DBIC will stagnate, the "new"
>> will not gain traction. Everybody loses.
>
> Agreed. Another,
>

 same here

 -1 for forking, +1 for the original proposal
>>>
>>> Mee too.
>>>
>>> +1 Matt's proposal (new project team)
>>> -1 Andrew's proposal (forking)
>>
>> Same here:
>>
>> +1 Matt's proposal
>> -1 to forking
>>
> 
> +1 Matt's proposal
> +1 to forking
> 

Sorry, the choices were confused by me - so my corrected vote is

+1 Matt's proposal (new project team)
-1 to forking

Regards
  Racke


-- 
Ecommerce and Linux consulting + Perl and web application programming.
Debian and Sympa administration.


___
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

Re: [Dbix-class] GOVERNANCE: Aggregation and conclusion

[David Precious]

>From me, it's a +1 to Matt's proposal (new project team) and -1 to
forking - I don't want to see the current DBIx::Class languishing, and
I think it's something far more valuable to be managed by a team.

As much as I respect riba for all the work he's put in, his recent
behaviour concerns me greatly, and doesn't leave me filled with
confidence of him being sole gatekeeper of the DBIx::Class namespace
and everything that relies upon it - and even if I still had full faith
in him being the man for the job, the bus factor is too low for
something so important.

Whilst, yes, people could change to "use DBIx::Class2" or whatever a new
fork was called if they want the new stuff, that's a lot of
already-out-there code relying on something with a single maintainer,
and a lot of CPAN dists which depend on DBIx::Class which would need to
decide which version to target, etc.



On Wed, 2 Nov 2016 10:11:25 +0100
"Stefan Hornburg (Racke)"  wrote:
> I think we should at least give interested developers a chance to play
> with DBIx::Class and test out new features.
> 
> It can just live on Github and not on CPAN until something useful
> emerges out of it. In case that doesn't happen, the repo can
> be closed.

Being on GitHub, people can arbitrarily fork with one click to their own
repository, play with it as they wish, and if they end up with
something they think is good and useful, offer to contribute it back.

Isn't that what GitHub is /for/? :)


___
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

Re: [Dbix-class] The email I didn't want to write.

[Christian Walde]

On Wed, 02 Nov 2016 11:50:24 +0100, Peter Rabbitson  
 wrote:



rabbit@Ahasver:~/devel/schema_loader$ perl_git_stats lib t

rabbit@Ahasver:~/devel/sqla$ perl_git_stats lib t


I don't think mst was trying to talk away contributions of others, but  
saying that you've talked about a *current active maintainer*.


ilmari has been, respectively, for 2† and 4‡ years the only consistently  
active person on the mentioned dists, which remains true even in the face  
of his commit counts being lower than those of previous contributors.


†  
https://github.com/dbsrgits/sql-abstract/graphs/contributors?from=2014-10-03=2016-11-02=c


‡  
https://github.com/dbsrgits/dbix-class-schema-loader/graphs/contributors?from=2011-10-28=2016-11-02=c


(Double-click on the time graph to expand to all of it, or click and drag  
to inspect timeframe.)


--
With regards,
Christian Walde

___
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

Re: [Dbix-class] The email I didn't want to write.

[Peter Rabbitson]

On 11/02/2016 11:50 AM, Peter Rabbitson wrote:


P.S. All stats generated by the following script.It essentially
correlates deep-blame (ignoring whitespace changes and trying to detect
trans-file copies with default git settings), with the type of file region.

https://gist.github.com/ribasushi/600bcbc0c84f5825b1236fb02c57dda3#file-perl_git_stats-pl



As excellent demonstration of why I should not be working given my 
current sleep schedule: the summing of the totals in the original script 
was wrong. As a result each 'As of XXX GRAND_TOTAL stats' in my 
preceding email is incorrect. The rest is unchanged.


Fix pushed to gist, rerun the stats locally for a better picture.
https://gist.github.com/ribasushi/600bcbc0c84f5825b1236fb02c57dda3/revisions

___
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

Re: [Dbix-class] GOVERNANCE: Aggregation and conclusion

[Peter Rabbitson]

On 10/31/2016 02:40 PM, Peter Rabbitson wrote:


Same here (wrt not wanting to re-live this situation again). I will
respond to the above points around midnight UTC ( ~11h from now ).



Apologies for my silence. The combination of a time-zone shift with an 
unusually early day-start leaves me way less "productive time" than I 
anticipated. I will publish a to-the-point workable proposal by the end 
of this week.


Stay tuned.

___
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

Re: [Dbix-class] The email I didn't want to write.

[Peter Rabbitson]

Matt, thank you for writing this email. It further highlights where we 
differ, and will serve as a good trampoline for me to distill my point 
further. There is a lot of stuff to unpack here, and given text is not 
my forte I will take my time to respond in full some time this weekend 
(along with my proposal).


I am going to only highlight a few of the inaccuracies below, as they 
require further comment on Matt's part.


On 11/01/2016 11:18 PM, Matt S Trout wrote:


...

This seems like a surprising description of ilmari, given he holds the
first-come permissions for both DBIx::Class::Schema::Loader and SQL::Abstract


PAUSE disagrees:

rabbit@Ahasver:~$ curl -s 
http://cpan.metacpan.org/modules/06perms.txt.gz | zgrep 
'^SQL::Abstract,.*,f$'

SQL::Abstract,MSTROUT,f


and conducted a huge and highly successful refactor of the former.


True, ilmari did work on S::L recently, but let's give credit where 
credit is due:


rabbit@Ahasver:~/devel/schema_loader$ perl_git_stats lib t
As of 4f1bda9 GRAND_TOTAL stats => {
  blank_lines => 7320,
  code_lines => 21874,
  comment_lines => 1027,
  pod_lines => 2584,
  total_lines => 32805
}
rkito...@cpan.org stats => {
  blank_lines => 3652,
  code_lines => 11265,
  comment_lines => 587,
  pod_lines => 957,
  total_lines => 16461
}
ilm...@ilmari.org stats => {
  blank_lines => 635,
  code_lines => 2634,
  comment_lines => 128,
  pod_lines => 564,
  total_lines => 3961
}
blbl...@gmail.com stats => {
  blank_lines => 1061,
  code_lines => 2435,
  comment_lines => 62,
  pod_lines => 424,
  total_lines => 3982
}



...

Meanwhile, we've now reached a point where seeing a ticket or patch sent in
by ribasushi tends to result in people ignoring it for a few days because
they need to work up the emotional stoicism required to deal with the chances
of it being a useful patch/ticket that happens to come with a free polemic.


Citation needed. Please provide an example where I have been abusive or 
even slightly unprofessional in a bugreport. Issue trackers are 
generally always part of the public record, so it shouldn't be a problem 
to back up what was said above.




...

- who's actively attacked and/or alienated the owners of many of our downstream
  dependencies, including the crucial SQL::Abstract


Even correcting for the error of who the actual SQLA owner is, here are 
the stats of the top 6 contributors:


rabbit@Ahasver:~/devel/sqla$ perl_git_stats lib t
As of 18710f6 GRAND_TOTAL stats => {
  blank_lines => 2540,
  code_lines => 12460,
  comment_lines => 775,
  misc_lines => 2,
  pod_lines => 2219,
  total_lines => 17996
}
ribasu...@cpan.org stats => {
  blank_lines => 494,
  code_lines => 3594,
  comment_lines => 259,
  pod_lines => 322,
  total_lines => 4669
}
fri...@gmail.com stats => {
  blank_lines => 211,
  code_lines => 1087,
  comment_lines => 12,
  pod_lines => 106,
  total_lines => 1416
}
no...@nix.hu stats => {
  blank_lines => 97,
  code_lines => 925,
  comment_lines => 35,
  pod_lines => 45,
  total_lines => 1102
}
ash_git...@firemirror.com stats => {
  blank_lines => 290,
  code_lines => 553,
  comment_lines => 25,
  pod_lines => 414,
  total_lines => 1282
}
laurent.d...@etat.ge.ch stats => {
  blank_lines => 410,
  code_lines => 548,
  comment_lines => 99,
  misc_lines => 2,
  pod_lines => 309,
  total_lines => 1368
}
ilm...@ilmari.org stats => {
  blank_lines => 16,
  code_lines => 195,
  comment_lines => 13,
  pod_lines => 27,
  total_lines => 251
}

If we look at SQL::Abstract alone (which arguably should have been the 
only thing in the dist, but I dropped the ball there), we still get:


rabbit@Ahasver:~/devel/sqla$ perl_git_stats lib/SQL/Abstract.pm
As of 18710f6 GRAND_TOTAL stats => {
  blank_lines => 1300,
  code_lines => 1889,
  comment_lines => 251,
  misc_lines => 1,
  pod_lines => 1890,
  total_lines => 5331
}
ribasu...@cpan.org stats => {
  blank_lines => 161,
  code_lines => 536,
  comment_lines => 56,
  pod_lines => 254,
  total_lines => 1007
}
laurent.d...@etat.ge.ch stats => {
  blank_lines => 321,
  code_lines => 332,
  comment_lines => 84,
  misc_lines => 1,
  pod_lines => 276,
  total_lines => 1014
}
ash_git...@firemirror.com stats => {
  blank_lines => 251,
  code_lines => 99,
  comment_lines => 11,
  pod_lines => 414,
  total_lines => 775
}
no...@nix.hu stats => {
  blank_lines => 20,
  code_lines => 72,
  comment_lines => 7,
  pod_lines => 18,
  total_lines => 117
}
ilm...@ilmari.org stats => {
  blank_lines => 16,
  code_lines => 57,
  comment_lines => 10,
  pod_lines => 27,
  total_lines => 110
}

Matt, with all said above - can you please clarify:


- who's actively attacked and/or alienated the owners of many of our downstream
  dependencies, including the crucial SQL::Abstract


Cheers


P.S. All stats generated by the following script.It essentially 
correlates deep-blame (ignoring whitespace changes and trying to detect 
trans-file copies with default git settings), with the type of file region.

Re: [Dbix-class] GOVERNANCE: Aggregation and conclusion

[Paul Mooney]

On 02.11.2016 09:02, Dave Cross wrote:

Quoting Matthias Zeichmann :

On Tue, Nov 1, 2016 at 10:45 PM, Charlie Garrison 


wrote:


On 1 Nov 2016, at 19:48, Thomas Klausner wrote:

> I think a fork will not work. The "old" DBIC will stagnate, the "new"
> will not gain traction. Everybody loses.

Agreed. Another,



same here

-1 for forking, +1 for the original proposal


Mee too.

+1 Matt's proposal (new project team)
-1 Andrew's proposal (forking)


Same here:

+1 Matt's proposal
-1 to forking


___
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

Re: [Dbix-class] GOVERNANCE: Aggregation and conclusion

[Dave Cross]

Quoting Matthias Zeichmann :


On Tue, Nov 1, 2016 at 10:45 PM, Charlie Garrison 
wrote:


On 1 Nov 2016, at 19:48, Thomas Klausner wrote:

> I think a fork will not work. The "old" DBIC will stagnate, the "new"
> will not gain traction. Everybody loses.

Agreed. Another,



same here

-1 for forking, +1 for the original proposal


Mee too.

+1 Matt's proposal (new project team)
-1 Andrew's proposal (forking)

Dave...



___
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

Re: [Dbix-class] GOVERNANCE: Aggregation and conclusion

[Matthias Zeichmann]

On Tue, Nov 1, 2016 at 10:45 PM, Charlie Garrison 
wrote:

> On 1 Nov 2016, at 19:48, Thomas Klausner wrote:
>
> > I think a fork will not work. The "old" DBIC will stagnate, the "new"
> > will not gain traction. Everybody loses.
>
> Agreed. Another,
>

same here

-1 for forking, +1 for the original proposal
-- 
siggen.pl: Segmentation Fault
___
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