Re: [Dbix-class] GOVERNANCE: An actually concrete proposal w/bootstrap governance system

[Jonathan Scott Duff]

On Tue, Oct 18, 2016 at 2:58 PM, Wallace Reis  wrote:

> On October 18, 2016 at 4:04:17 PM, Leo Lapworth (l...@cuckoo.org) wrote:
> > On 18 October 2016 at 17:51, Matt S Trout wrote:
> >
> > > =begin GOVERNANCE
> > >
> > .
> > > =end GOVERNANCE
> > >
> > > What say ye?
> >
> > This gets the governance issue resolved and puts in place a framework
> that
> > can evolve to fit what is needed at the time.
> >
> > +1
> >
> > Anything more is just detail which can be added as required by the
> > community or core updating the governance in accordance with these rules.
>
> +1 # this pretty much summarizes my position.
>

Aye, me too.  +1


-Scott


>
> Cheers!
>
> --
> 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
>
___
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] ★ VOTE NOW: DBIC Governance and Namespace Control ★

[Jonathan Scott Duff]

Proposal A

-Scott

On Mon, Dec 5, 2016 at 12:15 AM, 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 

Re: [Dbix-class] Decision time: which fork inherits the existing DBIx::Class namespace

[Jonathan Scott Duff]

On Fri, Dec 2, 2016 at 11:50 PM, Peter Rabbitson 
wrote:

> Greetings,
>

Greetings and salutations to you Peter  :-)


>
> As such, and despite protests[2], I am essentially obligated to
> kickstart a DBIx::Class fork free of "community bias" ( note:
> "community", which was clearly set apart from "user base" in the past
> months ).
>

Hmm.  This is unfortunate.  Even if the fork is for the good of the user
base,
there will still be confusion about which DBIx::Class is the "right" or
"best"
one from existing users and potential future users.  And what would be
available to help developers explain this fork to their managers
(especially if
the list of dependencies does change as mentioned below)?


>
> The distribution will be governed by the proven BDFL model, although a
> lot of the details will get formalized in a document supplied with the
> distribution. The effect of uncertainty in this area turned out to be
> too great not to address going forward.
>
>
> The name of the fork is not interesting - the important thing is that it
> will continue providing the DBIx::Class namespace ( via a novel method,
> with safe-by-default conflict-resolution at install time, very much
> *un*like the Alt convention ). This means that a user willing to
> "switch" will have to adjust nothing more than their list of dependencies.
>

I'd be interested in hearing more about how the fork would be providing the
DBIx::Class namespace safely.  If someone were to switch from one
DBIx::Class to the other, how difficult would that be?

With all that said the outstanding question to the user-base is: given
> that a fork is unavoidable, and given technical means allow both forks
> to coexist on CPAN you must come to an agreement and instruct the PAUSE
> admins which of the two (mildly incompatible dists) should `cpan
> DBIx::Class` be resolving to.
>

My vote would be for "cpan DBIx::Class" to install the team-led DBIx::Class.
I am swayed by pragmatism and the bus number arguments.

-Scott
___
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