Fwd: Re: GOVERNANCE: An actually concrete proposal w/bootstrap governance system

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Fwd: Re: GOVERNANCE: An actually concrete proposal w/bootstrap governance system

Chris Prather
I suck at email and this got bounced initially.

-Chris

Begin forwarded message:

From: Chris Prather <[hidden email]>
Date: Oct 18, 2016 at 11:56 PM
To: DBIx::Class user and developer list <[hidden email]>
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


_______________________________________________
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
|  
Report Content as Inappropriate

Re: Fwd: Re: GOVERNANCE: An actually concrete proposal w/bootstrap governance system

John SJ Anderson
>> From: Chris Prather <[hidden email]>
>> Date: Oct 18, 2016 at 11:56 PM
>> To: DBIx::Class user and developer list <[hidden email]>
>> 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.
>>
>> ----


+1 to all Chris’s suggestions.

john.


_______________________________________________
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
|  
Report Content as Inappropriate

Re: Fwd: Re: GOVERNANCE: An actually concrete proposal w/bootstrap governance system

Dave Howorth
On 2016-10-19 05:07, John SJ Anderson wrote:

>>> From: Chris Prather <[hidden email]>
>>> Date: Oct 18, 2016 at 11:56 PM
>>> To: DBIx::Class user and developer list <[hidden email]>
>>> 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.
>>>
>>> ----
>
>
> +1 to all Chris’s suggestions.
>
> john.

I agree with Chris's observations too. It struck me that Matt's original
voting proposals would mean that the community had no effect in
practice; Chris's proposal seems to overcome that.

So +1 to Chris's suggestions
and -1 to the original proposal as proposed.

Cheers, Dave

PS In constructing low-energy buildings it is vital to achieve an
excellent degree of airtightness, which is not familiar to most
builders. One way to achieve it is by nominating an 'airtightness
champion' but that only works if the champion has the power to stop work
and even order rework. I see a parallel.

_______________________________________________
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
|  
Report Content as Inappropriate

Re: Fwd: Re: GOVERNANCE: An actually concrete proposal w/bootstrap governance system

Darin McBride
On Wednesday October 19 2016 11:20:43 AM Dave Howorth wrote:

> On 2016-10-19 05:07, John SJ Anderson wrote:
> >>> From: Chris Prather <[hidden email]>
> >>> Date: Oct 18, 2016 at 11:56 PM
> >>> To: DBIx::Class user and developer list <[hidden email]>
> >>> 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.
> >>>
> >>> ----
> >
> > +1 to all Chris’s suggestions.
> >
> > john.
>
> I agree with Chris's observations too. It struck me that Matt's original
> voting proposals would mean that the community had no effect in
> practice; Chris's proposal seems to overcome that.
>
> So +1 to Chris's suggestions
> and -1 to the original proposal as proposed.
>
> Cheers, Dave
>
> PS In constructing low-energy buildings it is vital to achieve an
> excellent degree of airtightness, which is not familiar to most
> builders. One way to achieve it is by nominating an 'airtightness
> champion' but that only works if the champion has the power to stop work
> and even order rework. I see a parallel.

This is no different in most fields - when you have something of utmost
importance, you assign it to someone (or some group of people), and if things
don't pass their review, all work halts.  We do the same thing with security
at $work - if the security team doesn't sign off, it doesn't ship.

Also, this seems to fall in line with an earlier proposal to make the fifth
person "compatibility minded" which then earned a rebuke that such things
cannot be added after the fact.  However, it can - if the person in charge of
such things has an absolute veto over shipping (in this case, a non-dev CPAN
upload).

Chris's latter two suggestions are along the line of my own, but stricter and
clearer, so I would add +1 to those suggestions as well.  If you want to say
the community has a say, this puts some teeth behind it.  (Suggestion #1 I
would abstain from voting on :) )

_______________________________________________
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
|  
Report Content as Inappropriate

Re: Fwd: Re: GOVERNANCE: An actually concrete proposal w/bootstrap governance system

Matt S Trout-2
On Wed, Oct 19, 2016 at 12:22:07PM -0600, Darin McBride wrote:

> Also, this seems to fall in line with an earlier proposal to make the fifth
> person "compatibility minded" which then earned a rebuke that such things
> cannot be added after the fact.  However, it can - if the person in charge of
> such things has an absolute veto over shipping (in this case, a non-dev CPAN
> upload).
>
> Chris's latter two suggestions are along the line of my own, but stricter and
> clearer, so I would add +1 to those suggestions as well.  If you want to say
> the community has a say, this puts some teeth behind it.  (Suggestion #1 I
> would abstain from voting on :) )

I quite like Chris' thoughts overall, but feel like adding them by modifying
my proposal a-priori and effectively unilaterally-albeit-via-consultation
would unfairly prejudice the parts I like over the parts I'm less keen on,
so I'm going to leave the bootstrap proposal as-is.

However I would note that having the voting system tweaked using the voting
system as one of the first uses of the voting system is absolutely something
that was supposed to be possible, and would strike me as a pretty decent
validation that the self-modifying approach can at least theoretically work.

--
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
|  
Report Content as Inappropriate

Re: Fwd: Re: GOVERNANCE: An actually concrete proposal w/bootstrap governance system

Alexander Hartmaier
In reply to this post by Chris Prather
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 <[hidden email]>
Date: Oct 18, 2016 at 11:56 PM
To: DBIx::Class user and developer list <[hidden email]>
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@...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fwd: Re: GOVERNANCE: An actually concrete proposal w/bootstrap governance system

Matt S Trout-2
My timing sucks:

Day changed to 21 Oct 2016
07:17 -!- abraxxa [~[hidden email]] has joined #dbic-cabal
15:57 -!- abraxxa [~[hidden email]] 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 <[hidden email]<mailto:[hidden email]>>
> Date: Oct 18, 2016 at 11:56 PM
> To: DBIx::Class user and developer list <[hidden email]<mailto:[hidden email]>>
> 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@...


--
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
|  
Report Content as Inappropriate

Re: Fwd: Re: GOVERNANCE: An actually concrete proposal w/bootstrap governance system

Matt S Trout-2
... accurate though that last email might have been, it was meant to be an
off-list reply. I'm an idiot. Oh well.

--
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@...
Loading...