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

[Matt S Trout]

On Mon, Nov 07, 2016 at 12:23:36PM +0100, Peter Rabbitson wrote:
> On 11/02/2016 11:53 AM, Peter Rabbitson wrote:
> >I will publish a to-the-point workable proposal by the end
> >of this week.
> >
> 
> Apologies for the delay yet again. Recent emails made articulating
> my point more difficult, so I am still thinking on how to properly
> respond. There are too many misconception (like e.g. that a fork is
> avoidable), and a manner of addressing them all still evades me.

Yeah, that's why I asked for monday, let me spend the weekend thinking.

Plus it was easier for me since I already had most of a proposal and
just needed to edit it.

Meanwhile, given I responded to your 'citation needed' request, it'd be
much appreciated if you could respond to my p5p question in the mean time;
I did my best to ask the question in an unprejudicial fashion, and I think
your answer should also help to further highlight where we differ.

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

[Peter Rabbitson]

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

I will publish a to-the-point workable proposal by the end
of this week.



Apologies for the delay yet again. Recent emails made articulating my 
point more difficult, so I am still thinking on how to properly respond. 
There are too many misconception (like e.g. that a fork is avoidable), 
and a manner of addressing them all still evades me.


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] GOVERNANCE: Aggregation and conclusion

[Darren Duncan]

All authors ARE copyright holders, unless they expressly disclaim or transfer 
said rights, which isn't usually the case with CPAN modules.


Due to all of the copyright holders licensing their contributions under an open 
source license, anyone is legally empowered to create a fork.


It is important to realize that the current governance issue under discussion is 
actually more akin to trademark rights than copying rights, in a sense; it is 
about who has the canonical privilege for the NAME "DBIx::Class" within the 
context of PAUSE/CPAN.


-- Darren Duncan

On 2016-11-07 1:07 AM, Hartmaier Alexander wrote:

I find it funny that people are discussing forking. If there are so many that
want a fork why hasn't someone already done it?
It seems most forget that DBIC is open source software. The license doesn't
hinder anyone from forking.
The license [1] says on the first two lines:

|DBIx::Class is Copyright (c) 2005-2016 by mst, castaway, ribasushi, and 
others. |||See AUTHORS and LICENSE included with this distribution. All rights 
reserved.| |

Are all authors also 'Copyright Holders'? If yes how does this affect the
current situation?
Imho DBIC isn't 'owned' by anybody, not even after contributing for years like
ribasushi did.

Until someone comues up with another proposal I'm +1 for msts.

Best regards, Alex

[1] https://metacpan.org/source/RIBASUSHI/DBIx-Class-0.082840/LICENSE



___
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

[Hartmaier Alexander]

I find it funny that people are discussing forking. If there are so many that 
want a fork why hasn't someone already done it?
It seems most forget that DBIC is open source software. The license doesn't 
hinder anyone from forking.
The license [1] says on the first two lines:

DBIx::Class is Copyright (c) 2005-2016 by mst, castaway, ribasushi, and others.
See AUTHORS and LICENSE included with this distribution. All rights reserved.


Are all authors also 'Copyright Holders'? If yes how does this affect the 
current situation?
Imho DBIC isn't 'owned' by anybody, not even after contributing for years like 
ribasushi did.

Until someone comues up with another proposal I'm +1 for msts.

Best regards, Alex

[1] https://metacpan.org/source/RIBASUSHI/DBIx-Class-0.082840/LICENSE


*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
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

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

[Nigel Metheringham]

I have a distinct feeling that this discussion is going deja vu all over
again, but from my point of view I vote:-

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



-- 

[ Nigel Metheringham -- ni...@dotdot.it ] 
[ Ellipsis Intangible Technologies  ]
 



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

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

[Charlie Garrison]

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,

-1

Charlie

-- 

   Charlie Garrison  
   github.com/cngarrison   metacpan.org/author/CNG

___
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

[Renvoize, Martin]

Totally agree with Ashley there, could not have said it better myself

"Ashley Pond V" wrote:
>
> +1 for the fork. It's the only way to eat our cake and have it;
> affording different lines of development and culture without friction
> and strife.
___
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

[Ashley Pond V]

+1 for the fork. It's the only way to eat our cake and have it;
affording different lines of development and culture without friction
and strife.

Since very few, if any, of you were here at the beginning, you
probably don't know that this is essentially how DBIx::Class was born;
as an indirect fork from Class::DBI. It was the right thing then. It's
the right thing now. I adore and am grateful for MST's experiments and
use them whenever I can. On the other side, I was the one who
introduced DBIC at Fortune company #5, so stability and speed have
become the most important concerns to me and my group.

___
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

[Thomas Klausner]

Hi!

On Mon, Oct 31, 2016 at 08:18:13AM -0400, James E Keenan wrote:
> On 10/31/2016 07:22 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.

-1

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

Greetings,
domm


-- 
#!/usr/bin/perl  http://domm.plix.at
for(ref bless{},just'another'perl'hacker){s-:+-$"-g&$_.$/}

___
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

[Fernan Aguero]

+1 for the fork

On Mon, Oct 31, 2016 at 6:24 PM, Darren Duncan 
wrote:

> My current thought is that a fork may be the best solution in the short
> term, with the following clarifications or amendments.
>
> 1. Peter Rabbitson would have the exclusive PAUSE permissions to the
> DBIx::Class namespace and would continue to perform releases of his work on
> it as he wanted to do.  He would also designate others to have those
> permissions as he chooses, and he would choose his own successor.  This
> namespace would emphasize stability and/or Peter's objectives.
>
> 2. Matt would create a fork using his proposed governance model to further
> evolve along those lines.  The fork would emphasize their objectives, and
> would probably include most major work not done by Peter.
>
> 3. I hope that Peter would still be open to pull requests but he should
> publish some documentation giving an outline of what qualities he would
> look for in patches from others so they would more likely be accepted.  My
> assumption however, is that in a fork scenario most pull requests would
> just go to the fork, and pull requests on the original would be limited to
> small things like security or bug fixes.
>
> 4. In the future, if Peter decides to leave again and/or there is no
> successor, the DBIx::Class namespace can be treated according to abandoned
> module protocol, where Peter has no outstanding interest, unlike now.
>
> 5. Ideally DBIC, both versions, would be as duck-typed as possible with
> its API, so that dependent modules or applications could switch between
> them more easily, without having to do a lot of tests on the names of
> classes.
>
> This all being said, I am ALSO fine with Matt's governance proposal being
> used with the DBIx::Class namespace, though given that Peter's further
> committer involvement is basically mutually exclusive with this, I consider
> it less ideal for that reason.
>
> I also recognize that DBIC has its own network of extensions, and I don't
> know if they are duck-typed or not, eg would they themselves need
> substantial or any changes to work in a forked ecosystem, or if one could
> use them with both different-names DBIC versions unchanged.
>
> I see that as a main complicating factor.  Applications, not so much; if
> they want stability, Peter's version should serve them; if they want
> substantial changes or new features that more likely may be in the fork,
> they would have to be changed anyway.
>
> -- 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
>



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

[Dmitry Bigunyak]

>On Mon, 31 Oct 2016 00:43:31 Matt S Trout < m...@shadowcat.co.uk > 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.
>
>The advantages of this proposal are:
>
>1. Users get a choice. If they are happy with the current feature set
>and need rock-solid performance and stability, then they can use DBIC.
>If they need new features or want to use a module that has a quicker
>development pace, then they can use DBIC2.
>
>2. Ribasushi continues to contribute to the code base, both in terms of
>potentially migrating proven-solid features from DBIC2 to DBIC, and in
>terms of keeping his expertise engaged.
>
>Andy
>

+1 to the "fork proposal" as the solution which should satisfy most of the 
people.
I don't really share concerns regarding the team fragmentation, instead having 
a choice and maybe even healthy competition is definitely a good thing.

--
Dmitry Bigunyak
___
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]

My current thought is that a fork may be the best solution in the short term, 
with the following clarifications or amendments.


1. Peter Rabbitson would have the exclusive PAUSE permissions to the DBIx::Class 
namespace and would continue to perform releases of his work on it as he wanted 
to do.  He would also designate others to have those permissions as he chooses, 
and he would choose his own successor.  This namespace would emphasize stability 
and/or Peter's objectives.


2. Matt would create a fork using his proposed governance model to further 
evolve along those lines.  The fork would emphasize their objectives, and would 
probably include most major work not done by Peter.


3. I hope that Peter would still be open to pull requests but he should publish 
some documentation giving an outline of what qualities he would look for in 
patches from others so they would more likely be accepted.  My assumption 
however, is that in a fork scenario most pull requests would just go to the 
fork, and pull requests on the original would be limited to small things like 
security or bug fixes.


4. In the future, if Peter decides to leave again and/or there is no successor, 
the DBIx::Class namespace can be treated according to abandoned module protocol, 
where Peter has no outstanding interest, unlike now.


5. Ideally DBIC, both versions, would be as duck-typed as possible with its API, 
so that dependent modules or applications could switch between them more easily, 
without having to do a lot of tests on the names of classes.


This all being said, I am ALSO fine with Matt's governance proposal being used 
with the DBIx::Class namespace, though given that Peter's further committer 
involvement is basically mutually exclusive with this, I consider it less ideal 
for that reason.


I also recognize that DBIC has its own network of extensions, and I don't know 
if they are duck-typed or not, eg would they themselves need substantial or any 
changes to work in a forked ecosystem, or if one could use them with both 
different-names DBIC versions unchanged.


I see that as a main complicating factor.  Applications, not so much; if they 
want stability, Peter's version should serve them; if they want substantial 
changes or new features that more likely may be in the fork, they would have to 
be changed anyway.


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

[Andrew Beverley]

On Mon, 31 Oct 2016 11:22:32 -0400 David Golden  wrote:
> Please read the section entitled "=== Future Plans" in this message
> from Peter:
> http://www.nntp.perl.org/group/perl.modules/2016/10/msg96174.html
> 
> What I suggested was not a hypothetical "train-smash" intended to
> scare you or others.  It was literally his plan for DBIC as of Oct 1.

I wouldn't call that a train-smash. In fact, I'd call it the complete
opposite (if such a thing exists, maybe a power cut to the whole rail
network).

I agree it was a poor proposal, and certainly not something I wanted to
see happen, but it was what he believed was best at the time to ensure
continued stability (arguable, but I'm referring to intent).

That's no longer his plan though, a new proposal is on the table, and
a re-evaluation of the options is required by the user base.

Andy

___
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 Golden]

On Mon, Oct 31, 2016 at 10:18 AM, Andrew Beverley  wrote:

> On Mon, 31 Oct 2016 10:12:27 -0400 David Golden  wrote:
> > So to be absolutely clear, it sounds like proposal "B" is to grant
> > Peter the unilateral power initially in dispute.
> >
> > I.e. he could – on arbitrary day N after your proposal is adopted –
> > merge his remaining work, transfer permissions to an unknown person
> > with an unknown mandate, and retire (aka. the original "project
> > freeze" plan).
>
> Yes, correct, just like lots of other "upstream" module maintainers
> could do the same.
>
> Like I say, I personally trust him not to cause such a train-smash


Please read the section entitled "=== Future Plans" in this message from
Peter: http://www.nntp.perl.org/group/perl.modules/2016/10/msg96174.html

What I suggested was not a hypothetical "train-smash" intended to scare you
or others.  It was literally his plan for DBIC as of Oct 1.

In making your proposal "B", you are indicating that you support that
specific plan if that's what Peter decides is best for DBIC now or at any
point in the future.

Again, I have no objections if the DBIC community gives informed consent to
such a plan.  Speaking personally, I can understand the appeal of such
certainty around stability.

I, too, look forward to Peter's thoughts, as perhaps his thinking on the
matter has evolved since a month ago.

Regards,
David
___
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

[fREW Schmidt]

+1

On Mon, Oct 31, 2016 at 11:22:07AM +, 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.
> 
> The advantages of this proposal are:
> 
> 1. Users get a choice. If they are happy with the current feature set
> and need rock-solid performance and stability, then they can use DBIC.
> If they need new features or want to use a module that has a quicker
> development pace, then they can use DBIC2.
> 
> 2. Ribasushi continues to contribute to the code base, both in terms of
> potentially migrating proven-solid features from DBIC2 to DBIC, and in
> terms of keeping his expertise engaged.
> 
> Andy
> 
> [1] http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/012392.html
> [2] http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/012237.html
> 
> ___
> 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

-- 
fREW Schmidt
https://blog.afoolishmanifesto.com

___
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

[Aaron Trevena]

On 31 October 2016 at 12:18, James E Keenan  wrote:
> On 10/31/2016 07:22 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.
>>
>
> -1 on this proposal from me.  I favor getting on with the existing proposal.

Another -1 on new namespace, existing proposal seems more sustainable.

A.


-- 
Aaron J Trevena, BSc Hons
http://www.aarontrevena.co.uk
LAMP System Integration, Development and Consulting

___
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

[Michael Hamlin]

I am in favor of Andy's proposal (forking).  My current understanding is
there are developers interested in working in both directions, and this
proposal permits that to happen.

If the projects diverge, so be it.  If one ceases to be actively
maintained, so be it.  This is not unusual in OSS or CPAN.  End users will
always have the choice which to use (or continue using), or whether to
switch.

I do not think a "succession plan" is necessary for this proposal, because
I trust Peter to be responsible and responsive to the users, the fact that
abandoned repos can be reassigned, and that any written succession plan is
not necessarily going to actually help in an uncertain future.

As I said before, governance and direction do not seem to me entirely
independent discussions, and attempts to split them may depress user
involvement.  Its like voting for a candidate without knowing their
platform.  As an end-user, I care a lot about direction.  My feelings about
governance can change as I hear more about what folks are proposing to do.

thanks,
michael

p.s. I didn't appreciate the feeling of "rush to judgment" that this thread
began with.  I can understand that to some this discussion feels like its
dragging on, but if you want to listen to users, you need to give plenty of
time.  (I can't even read this mailing list on a daily basis, much less
cogitate and respond!)
___
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

[Andrew Beverley]

On Mon, 31 Oct 2016 14:18:59 Andrew Beverley  wrote:
> On Mon, 31 Oct 2016 10:12:27 -0400 David Golden  wrote:
> > So to be absolutely clear, it sounds like proposal "B" is to grant
> > Peter the unilateral power initially in dispute.
> > 
> > I.e. he could – on arbitrary day N after your proposal is adopted –
> > merge his remaining work, transfer permissions to an unknown person
> > with an unknown mandate, and retire (aka. the original "project
> > freeze" plan).
> 
> Yes, correct, just like lots of other "upstream" module maintainers
> could do the same.
> 
> Like I say, I personally trust him not to cause such a train-smash,
> but if others don't and would rather see him leave the project
> altogether, then the vote is their opportunity to say so (or under my
> proposal they could use DBIx::Class2 of course).

(I should add that this is just my view based on Riba's previous
comments. We should at least let him have his own point of view on the
matter, which he will presumably provide later today).

___
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

[Andrew Beverley]

On Mon, 31 Oct 2016 10:12:27 -0400 David Golden  wrote:
> So to be absolutely clear, it sounds like proposal "B" is to grant
> Peter the unilateral power initially in dispute.
> 
> I.e. he could – on arbitrary day N after your proposal is adopted –
> merge his remaining work, transfer permissions to an unknown person
> with an unknown mandate, and retire (aka. the original "project
> freeze" plan).

Yes, correct, just like lots of other "upstream" module maintainers
could do the same.

Like I say, I personally trust him not to cause such a train-smash, but
if others don't and would rather see him leave the project altogether,
then the vote is their opportunity to say so (or under my proposal they
could use DBIx::Class2 of course).

Andy

___
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 Golden]

On Mon, Oct 31, 2016 at 9:42 AM, Andrew Beverley  wrote:

> > Could you please clarify your proposal with details on that front and
> > what is to happen should Peter be unable or unwilling to continue
> > working on DBIC?
>
> It would be no different to any other module. Ribasushi nominates
> someone should he be able to, otherwise:
>
> http://www.cpan.org/misc/cpan-faq.html#How_adopt_module
>
> Personally I trust Ribasushi to make such a nomination, and I know
> others do. If there are more people that don't, then that's what this
> vote is for.
>
>
So to be absolutely clear, it sounds like proposal "B" is to grant Peter
the unilateral power initially in dispute.

I.e. he could – on arbitrary day N after your proposal is adopted – merge
his remaining work, transfer permissions to an unknown person with an
unknown mandate, and retire (aka. the original "project freeze" plan).

(Of course, given his change in employment circumstances, he might not do
that – he might faithfully continue to maintain DBIC for years to come.)

Speaking as PAUSE administrator, there is no objection to "B" if that's
what the community wants.  It would merely be another way for the community
to resolve the initial dispute.

Regards,
David

-- 
David Golden  Twitter/IRC/GitHub: @xdg
___
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

[Andrew Beverley]

On Mon, 31 Oct 2016 08:39:29 -0400 David Golden  wrote:
> On Mon, Oct 31, 2016 at 7:22 AM, Andrew Beverley  wrote:
> 
> > - RIBASUSHI retains the current namespace
> >
> >
> Peter previously said that he would only continue if all other
> maintainers relinquished their claims to the DBIC namespace [1].

Yes, that would be the case, as that would prevent this situation
happening again.

> Could you please clarify your proposal with details on that front and
> what is to happen should Peter be unable or unwilling to continue
> working on DBIC?

It would be no different to any other module. Ribasushi nominates
someone should he be able to, otherwise:

http://www.cpan.org/misc/cpan-faq.html#How_adopt_module

Personally I trust Ribasushi to make such a nomination, and I know
others do. If there are more people that don't, then that's what this
vote is for.

> If Peter agrees and your proposal carries, I don't want to be in a
> situation where we have to have this debate again if he decides to
> take his "well deserved retirement" after all

The only reason we're in this situation is because of MST's (perfectly
reasonable) claims to the namespace. This would clarify ownership once
and for all, and leave the decision with the module owner, as it
presumably is with all other modules.

Andy

___
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 01:39 PM, David Golden wrote:

On Mon, Oct 31, 2016 at 7:22 AM, Andrew Beverley > wrote:

- RIBASUSHI retains the current namespace


Peter previously said that he would only continue if all other
maintainers relinquished their claims to the DBIC namespace [1].  Could
you please clarify your proposal with details on that front and what is
to happen should Peter be unable or unwilling to continue working on DBIC?

If Peter agrees and your proposal carries, I don't want to be in a
situation where we have to have this debate again if he decides to take
his "well deserved retirement" after all (regardless of whether
immediately after the permissions change or some unknown time in the
future).


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




___
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

[Chase Whitener]

-1 from me, too.

On Mon, Oct 31, 2016 at 8:42 AM, Dagfinn Ilmari Mannsåker
 wrote:
> James E Keenan  writes:
>
>> On 10/31/2016 07:22 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.
>>>
>>
>> -1 on this proposal from me.  I favor getting on with the existing proposal.
>
> -1 from me too.  I think forking will harm both sides, as the
> already-limited contributor pool gets fragmented across two code bases.
>
>
> - ilmari
>
> --
> "The surreality of the universe tends towards a maximum" -- Skud's Law
> "Never formulate a law or axiom that you're not prepared to live with
>  the consequences of."  -- Skud's Meta-Law
>
>
> ___
> 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] GOVERNANCE: Aggregation and conclusion

[Leo Lapworth]

On 31 October 2016 at 11:22, 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.
>
> The advantages of this proposal are:
>
> 1. Users get a choice. If they are happy with the current feature set
> and need rock-solid performance and stability, then they can use DBIC.
> If they need new features or want to use a module that has a quicker
> development pace, then they can use DBIC2.
>
> 2. Ribasushi continues to contribute to the code base, both in terms of
> potentially migrating proven-solid features from DBIC2 to DBIC, and in
> terms of keeping his expertise engaged.
>
> Andy
>
> [1] http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/012392.html
> [2] http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/012237.html

If we are having a A vs B vote, someone needs to put together a proposal
that has been fully researched and working out governance processes
for the project(s) as a whole...

- If we are forking, is there ANY pretence of trying to maintain
interoperability
between the 2 namespaces, if there is how does that get governed?

- Can anyone other than Ribasushi have any say in DBIx::Class changes,
as I've just seen David comment, what happens when he does want to
retire again?

- I'm not sure the people previously mentioned would be interested
in working on a fork (DBIx::Class2), they might be, but someone would need
to discuss this with them and then come back to the list with a confirmation
of that.

These are only initial thoughts, there is much more detail that someone
would need to work through

We shouldn't start voting until there is a FULL researched and formal proposal,
rather than some general ideas about a possible direction.

Maybe someone could formally step forward to co-ordinate putting
together this alternative proposal?

Leo

___
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

[Patrick Meidl]

On Mon, Oct 31 2016, Dagfinn Ilmari Mannsåker  wrote:

> James E Keenan  writes:
> 
> > On 10/31/2016 07:22 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.
> >>
> >
> > -1 on this proposal from me.  I favor getting on with the existing proposal.
> 
> -1 from me too.  I think forking will harm both sides, as the
> already-limited contributor pool gets fragmented across two code bases.

-1 for the same reason.

patrick

-- 
Patrick Meidl, Mag.
Senior Expert Software Engineering

IST - Institute of Science and Technology Austria
Am Campus 1
A-3400 Klosterneuburg, Austria

R I21.EG.115 (Building West, BT01)
T +43 2243 9000 1313
E pme...@ist.ac.at
W https://icp.ist.ac.at/search/users/pmeidl



___
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

[Dagfinn Ilmari Mannsåker]

James E Keenan  writes:

> On 10/31/2016 07:22 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.
>>
>
> -1 on this proposal from me.  I favor getting on with the existing proposal.

-1 from me too.  I think forking will harm both sides, as the
already-limited contributor pool gets fragmented across two code bases.


- ilmari

-- 
"The surreality of the universe tends towards a maximum" -- Skud's Law
"Never formulate a law or axiom that you're not prepared to live with
 the consequences of."  -- Skud's Meta-Law


___
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 Golden]

On Mon, Oct 31, 2016 at 7:22 AM, Andrew Beverley  wrote:

> - RIBASUSHI retains the current namespace
>
>
Peter previously said that he would only continue if all other maintainers
relinquished their claims to the DBIC namespace [1].  Could you please
clarify your proposal with details on that front and what is to happen
should Peter be unable or unwilling to continue working on DBIC?

If Peter agrees and your proposal carries, I don't want to be in a
situation where we have to have this debate again if he decides to take his
"well deserved retirement" after all (regardless of whether immediately
after the permissions change or some unknown time in the future).

Speaking personally, what I like about Matt's governance proposal is that
it explicitly establishes a continuity plan.  I think any alternative
proposal ought to be equally clear about continuity and succession.

Regards,
David

[1]
http://dbix-class.35028.n2.nabble.com/IMPORTANT-A-discussion-of-DBIC-governance-and-future-development-td7578987i100.html#a7579158


-- 
David Golden  Twitter/IRC/GitHub: @xdg
___
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

[James E Keenan]

On 10/31/2016 07:22 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.



-1 on this proposal from me.  I favor getting on with the existing proposal.

Thank you very much.
Jim Keenan

___
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

[Andrew Beverley]

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.

The advantages of this proposal are:

1. Users get a choice. If they are happy with the current feature set
and need rock-solid performance and stability, then they can use DBIC.
If they need new features or want to use a module that has a quicker
development pace, then they can use DBIC2.

2. Ribasushi continues to contribute to the code base, both in terms of
potentially migrating proven-solid features from DBIC2 to DBIC, and in
terms of keeping his expertise engaged.

Andy

[1] http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/012392.html
[2] http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/012237.html

___
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 Golden]

On Sun, Oct 30, 2016 at 8:43 PM, Matt S Trout  wrote:

> As such, I petition the PAUSE administration to leave things alone while
> the
> community sorts things out
>
>
Sure.  We've always maintained that there was no rush and that discussion
was the best course of action.

I encourage those presenting alternate proposals to focus on governance,
not merely project direction, as I think it will benefit the community to
have a mechanism for determining direction, permissions, etc. not just now
but going forward.

Regards,
David


-- 
David Golden  Twitter/IRC/GitHub: @xdg
___
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]

(bcced again to the modules list)

On Sun, Oct 30, 2016 at 08:43:03AM +, Andrew Beverley wrote:
> Given that there was no formal vote, I think this is a somewhat hasty
> and unfair conclusion. It's a bit like having an election with only one
> party, having people vote, and then mentioning a second party later
> once the election's finished. I personally was just about to vote in
> favour of the "governance+core team" proposal, when I went through all
> the emails and came to the second conclusion.
> 
> Personally I would like to see a straightforward "A vs B" vote. Only
> then will I consider this a fair decision.

Excellent.

This entire argument exists because riba wanted to plan his succession (a
plan that he has always refused to explain) without even bothering to talk
to the user base.

I, personally, preferred to actually let the userbase decide what happened,
hence the (apparently insufficient) attempt at voting that riba grudgingly
agreed to.

I am entirely in favour of a multi-proposal vote, and will be happy to abide
by the result of the list aggregate vote.

If anybody wishes to make a third proposal, they probably should do so now.

Otherwise, I would suggest that you turn your plan into a full proposal, and
I have time to update my governance proposal, and then we allow Q about
both, and then we vote.

As such, I petition the PAUSE administration to leave things alone while the
community sorts things out, given it's clear that everybody except ribasushi
would prefer things to be decided by democracy than fiat.

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

[Dmitry Bigunyak]

>Given that there was no formal vote, I think this is a somewhat hasty
>and unfair conclusion. It's a bit like having an election with only one
>party, having people vote, and then mentioning a second party later
>once the election's finished. I personally was just about to vote in
>favour of the "governance+core team" proposal, when I went through all
>the emails and came to the second conclusion.
>
>Personally I would like to see a straightforward "A vs B" vote. Only
>then will I consider this a fair decision.
>
>Andy

Heh, I'm actually totally agree with that.
I was silently following the discussion and never had the feeling that all this 
time there was a voting process going on...
Matt, David, sorry guys, but it all feels like you just using the community to 
do what we've already decided to do.

--
Dmitry
e-mail: ices...@inbox.ru
___
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

[Charlie Garrison]

On 30 Oct 2016, at 19:43, Andrew Beverley wrote:

> Personally I would like to see a straightforward "A vs B" vote. Only
> then will I consider this a fair decision.

+1

-- 

   Charlie Garrison  
   github.com/cngarrison   metacpan.org/author/CNG

___
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

[Andrew Beverley]

On Sat, 29 Oct 2016 20:47:20 -0400 David Golden  wrote:
> I'm very pleased to see how the DBIC community has engaged in honest
> discussion about self-governance.  It's been a long road, but one
> that I think will serve the community well going forward.
> 
> I'll make the changes in the next 24-48 hours and make a final
> announcement when it's done.

Given that there was no formal vote, I think this is a somewhat hasty
and unfair conclusion. It's a bit like having an election with only one
party, having people vote, and then mentioning a second party later
once the election's finished. I personally was just about to vote in
favour of the "governance+core team" proposal, when I went through all
the emails and came to the second conclusion.

Personally I would like to see a straightforward "A vs B" vote. Only
then will I consider this a fair decision.

Andy

___
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 Golden]

On Sat, Oct 29, 2016 at 3:17 PM, Matt S Trout  wrote:

> As such, I hereby call upon the PAUSE administration to adjust the
> permissions
> for all namespaces within the DBIx::Class distribution in accordance with:
>
> http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/012365.html
>

I'm very pleased to see how the DBIC community has engaged in honest
discussion about self-governance.  It's been a long road, but one that I
think will serve the community well going forward.

I'll make the changes in the next 24-48 hours and make a final announcement
when it's done.

Regards,
David


-- 
David Golden  Twitter/IRC/GitHub: @xdg
___
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