My timing sucks:
Day changed to 21 Oct 2016
07:17 -!- abraxxa [~abra...@tsa-tc-flod-1.t-systems.at] has joined #dbic-cabal
15:57 -!- abraxxa [~abra...@tsa-tc-flod-1.t-systems.at] has quit [Quit:
Leaving.]
15:57 < mst> abraxxa: to be completely honest, I excluded you from my proposal
purely on the basis that I didn't want to see a four-page ribarant
about your "urge for shiny new things" :)
15:57 < mst> oh for FUCK's sake, he left literally while I was typing that
On Fri, Oct 21, 2016 at 04:44:16PM +0200, Hartmaier Alexander wrote:
> On 2016-10-19 05:58, Chris Prather wrote:
> I suck at email and this got bounced initially.
>
> -Chris
>
> Begin forwarded message:
>
> From: Chris Prather <perig...@prather.org<mailto:perig...@prather.org>>
> Date: Oct 18, 2016 at 11:56 PM
> To: DBIx::Class user and developer list
> <dbix-class@lists.scsys.co.uk<mailto:dbix-class@lists.scsys.co.uk>>
> Subject: Re: [Dbix-class] GOVERNANCE: An actually concrete proposal
> w/bootstrap governance system
>
> So I'm only a interested user of DBIC. I took enough DBA classes in college
> to make me painfully aware that I don't want to understand how DBIC does what
> it does. I'm just very happy it does it.
>
> I am however deeply vested in how the Perl community self-regulates, and as
> such I've read probably more of this thread (and the related threads) than is
> healthy for someone who really should be busy trying to find paying work.
> That said I think this Governance Policy has merit, there are only three
> changes I would recommend two need to be made nearly immutable at the outset
> to be effective, one has already been proposed and can be adopted later.
>
> ----
>
> 1) The list of people with PAUSE COMAINT permissions and the list of of
> Voting Members should always be identical. Best would be if FIRSTCOME were
> held in trust by some DBIC account similar to how XML permissions are held
> (https://metacpan.org/author/DAHUT), and everyone else on the VM list were
> strictly co-maint. This might be overly complicated for what is mostly
> symbolic reasons but it would go a long way to demonstrating the new
> Governance.
>
> If someone resigns from the VM then they are removed from COMAINT.
>
> 2) Voting Members and the LAV (List aggregate Vote) have unilateral veto
> power for any proposal. Meaning if any Voting Member or the LAV make an
> explicit -1 to a proposal. The Proposal as it stands *in that thread* is
> dead. It will need to be re-proposed in such a way that the vetoing member
> either assents or abstains. This protects minority voices. My preference
> would be to require unanimity of consent but that would IN MY OPINION simply
> open the process up to be gamed during it's infancy.
>
> Finally this has already been proposed but I would add my experience with the
> Moose community.
>
> 3) A full PROPOSAL is required to merge a topic branch into the mainline
> release branch.
>
> ----
>
> This is far more than I was planning on commenting but having read as much of
> all of the relvant threads as possible I don't think that the policy *as
> proposed* is as conservative as it should be to properly reflect the concerns
> of all members of the community who've been involved in the conversation to
> date.
>
> Thanks for your time in reading my ramblings.
>
> -Chris
>
>
>
>
> I'd hoped that such regulations (like YAPC::NAs code-of-conduct) aren't
> necessary but it seems they are... ;(
>
> 1) and 2) sounds reasonable to me, +1.
>
> Controlling changes to the (git) repo is imho more important than when a
> release is made, so I'm +1 for 3).
> Master, or the per supported major version branch if we have more than one
> some time in the future, should always be in a releasable state which has the
> advantage that each co-maintainer can cut a release regardless if (s)he was
> involved in the commits leading up to the current one.
> DBIC once followed the "release early, release often" policy which encouraged
> people to report bugs and contribute features. Not seeing a release in month
> which fixes a minor annoyance or bug turned me off very much.
>
> If the proposed core team and community or whoever will decide what will
> happen wants, I'd be glad and honored to keep my co-maintainer status for
> DBIC. I didn't step up as 'voice of stability' as I do know that my urge for
> shiny new things would hinder me to fulfill that expectation.
> I did listen and have hopefully learned enough from mst and ribasushi in the
> last ten years to find a middle course between adding features to core and
> not breaking the API.
>
> Thanks for all your efforts to make DBIC great again!
>
>
> *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
> 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@lists.scsys.co.uk
--
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
