Re: [Dbix-class] ★ VOTE NOW: DBIC Governance and Namespace Control ★

[Paul Mooney]

I vote for Proposal A

On 05.12.2016 06:15, David Golden wrote:

Thank you to everyone who has been participating in or just reading
the various governance discussions since my initial email to the DBIC
list of Oct 3. [1]

It's time to bring this to a conclusion.

Peter suggests that the question to consider is merely which fork gets
the "DBIx::Class" namespace indexed on CPAN.  While that may be all he
cares about, I feel it trivializes the discussions the community has
been having and the decision the community is being asked to make.

Without restating all the history to date, here are the facts of the
case that I think are most relevant to consider in understanding the
proposals at hand:

* Peter's original plan that started the dispute could be summarized
as "Peter takes sole control of the DBIx::Class namespace and does X",
where at that time the plan appeared to be "freeze and park
permissions with an unknown owner".

* The dispute process clearly indicated that Peter didn't have the
support of existing maintainers or the community for such a plan
sufficient to disregard his prior permissions agreement with Matt.

* Matt proposed a mechanism for the community to self-govern the DBIC
namespace and development, sharing power between maintainers and the
mailing list. (Revised proposal is linked as [2])

* Peter revealed that his new employment situation allows him to
continue development. [3]

* Given Peter's track record and renewed availability, some in the
community wanted to see an alternative proposal where Peter continued
DBIC and the community took forward "DBIC2"; Andrew Beverl formalized
a proposal [4].  In response to concerns about the proposal, Peter
volunteered to clarify the alternative proposal.

* Peter delivered an alternative proposal that could be summarized as
"Peter takes sole control of the DBIx::Class namespace and does X",
where at this time the plan appears to be "kickstart a DBIx::Class
fork free of community bias". [5]

Unfortunately for the community's deliberations, Peter has
consistently provided minimal details on his plans, particularly
regarding succession should he no longer be able to or wish to
continue development.  After Andrew Beverl's proposal, Peter said he
would clarify by Nov 1 [6].  This target date then slipped to Nov 5
[7], was pushed back again on Nov 7 [8], and pushed again to Nov 17 or
else Thanksgiving [9].  On November 10, in the middle of this sequence
of delays, I started a private email thread with Peter asking if there
was anything I could do to help him formalize his proposal, but the
thread stalled on the Nov 14.  On November 26, I received a separate
private email telling me I could set a deadline of Dec 1, if needed
[10].  In our continuation of the stalled thread at that point, Peter
and I briefly discussed what ultimately became his final proposal of
Dec 3.

I think some details in those private emails are relevant to the
decisions at hand, so now that Peter has released his proposal and
because Peter originally insisted that all discussions about DBIC be
public anyway, I am now posting the content of that private email
thread in full. [11]

Specifically, I want to call attention to Peter's description of the
future of DBIC as "two forks developed in parallel, by noncooperating,
openly adversarial teams" which I think is more indicative of the
stakes and situation than the simpler question of "where does the
DBIx::Class namespace point".  What an adversarial fork means for the
future of the repository, mailing list, bug trackers, module
ecosystem, and community itself, etc. is undefined and community
members may wish to consider that in their decision process.

Given Peter's stated intent to launch a "fork free of community bias",
it's clear there is no governance alternative for the community on the
table.  Matt's original proposal had enough support to be adopted
outright [12], has been amended with generally good feedback, and has
provisions for future self amendment.  I consider it operative in its
amended form as soon as this vote is concluded, with the only missing
piece being what specific namespaces it governs.

The question thus comes down to whether the community feels "official"
DBIC is best developed going forward by a self-governed community or
by a single individual with absolute control (with both the good and
ill that comes of that).  The community may wish to consider the track
record and personalities of everyone involved for both scenarios in
weighing a decision.

As there has been more than enough time spent on these topics and/or
waiting for clarification already, and since the options on the table
aren't materially altered from their earlier forms, I don't believe
further discussion, debate or new alternatives will provide better or
clearer options for the future of DBIC.  It is time for this dispute
to be resolved so everyone can move forward.

Therefore, I submit to the list the following two proposals:

* PROPOSAL 

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

[Dbix-class] How to debug?

[Paul Mooney]

Hello,

I have a bug that happens /sometimes/. Replicating it is a pain.
I would like advice on how to debug it...
Because I'm scratching my head.

If I run our full test suite (takes about 20 minutes) I sometimes get 
JOINs where there should not be JOINs. It's like something has been 
cached somewhere and it's remembering a previous query... but I can't 
see how they is possible...


My code is inside a Result class. It looks like this:

  my @some_items = 
$self->result_source->schema->resultset("FulfilmentItem")->search({fulfilment_item_status_id 
=> { -in => [5,9,69696969] } })->all;


But sometimes I get SQL generated *with JOINs*... WTF?:

SELECT me.id, 
FROM fulfilment_item me
JOIN fulfilment fulfilment ON fulfilment.id = me.fulfilment_id
LEFT JOIN mts_hook mts_hook ON mts_hook.fulfilment_item_id = me.id
WHERE ( ( ( fulfilment.allocation_id = ? OR fulfilment.allocation_id = ? 
OR fulfilment.allocation_id = ? OR fulfilment.allocation_id = ? ) AND 
fulfilment_item_status_id IN ( ?, ?, ? ) ) )
: 'taBE4E1BE6-07D9-11E6-9001-984A2B909FEA', 
'taBF55B3A0-07D9-11E6-9001-984A2B909FEA', 
'taC09556B2-07D9-11E6-9001-984A2B909FEA', 
'taC1DCBE98-07D9-11E6-9001-984A2B909FEA', '5', '9', '69696969'


If I run the test on its own there are no JOINs.

perl v5.20.3
DBIx::Class::VERSION = 0.082820

Any ideas?
All advice welcome.


___
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