Re: [Dbix-class] IMPORTANT: A discussion of DBIC governance and future development

[Hartmaier Alexander]

And you think that when there are not even enough contributors for DBIC itself 
that will get better when there are two project instead of just one?

I doubt that...

On 2016-10-24 08:23, Renvoize, Martin wrote:
+1 for the DBIC2 namespace and the split being original stable dbic on the 
primary space.

I think this give's the most stability to the users, and at the same time give 
the development team the most space for innovating into new and exciting area's 
should they wish to.  Seems like a win-win to me!  Stable, performance and bug 
fix related releases on original DBIC along with a stable api upon which 
plugins and the current ecosystem should all continue to work.  New exiting 
features, possible non-backcompat api changes and experimentation on the new 
dbic2 namespace.

So yes, +1 from me for this split approach!


Martin Renvoize


Development Manager







T: +44 (0) 1483 378728


F: +44 (0) 800 756 6384


E: martin.renvo...@ptfs-europe.com


www.ptfs-europe.com





[https://www.ptfs-europe.com/wp-content/uploads/2014/09/ptfs_logo1.png]






Registered in the United Kingdom No. 06416372   VAT Reg No. 925 7211 30


The information contained in this email message may be privileged, confidential and 
protected from disclosure. If you are not the intended recipient, any dissemination, 
distribution or copying is strictly prohibited. If you think that you have received 
this email message in error, please email the sender at 
i...@ptfs-europe.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



*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
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] IMPORTANT: A discussion of DBIC governance and future development

[fREW Schmidt]

I think the proposal is that LTS continues with BDFL and the 2x version
uses the new protocol.

As for two git branches: this is about cpan, not git. Typical projects will
surely not be pulling from git, and I would not expect projects that do to
have any expectations of stability (as it is today.)

-- 
sent from a rotary phone, pardon my brevity
___
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] IMPORTANT: A discussion of DBIC governance and future development

[James E Keenan]

On 10/24/2016 07:11 AM, Leo Lapworth wrote:


Can we agree on the new governance... first?

Then IF (and so far no one seems to have suggested plans for this)
there is ever a change that could cause instability or break backwards
compat or has any major risk, the voting policy can be enacted to work
out what the community wants, new name space for testing with a policy
of 6 month release before merging back into main or what ever it
maybe, but that is SEPARATE to the governance issue.

To me these are two separate issues and it would be good to close off
the governance issue before moving onto detail of how to run the
project.

Thanks

Leo




+1 to closing off the governance discussion and moving forward with our 
lives :-)


jimk


___
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] IMPORTANT: A discussion of DBIC governance and future development

[Leo Lapworth]

On 23 October 2016 at 23:11, Darren Duncan  wrote:
> On 2016-10-23 3:04 PM, Karen Etheridge wrote:
>>
>>  > I also like the idea of default dbic being the stable one, and the
>> dbic2
>> being opt in. +1
>>
>> I don't see how it could credibly be the other way. There is no way to get
>> informed consent from all the existing DBIx::Class users to ensure that
>> they
>> understand they are getting bleeding-edge code. Moving to a more risky
>> configuration must always be done intentionally.
>
>
> Those are my thoughts exactly.  If DBIC ever started using multiple
> namespaces to distinguish LTS from bigger changes, the LTS should always
> have the existing name.  Users should always get the "safe" option by
> default and explicitly opt-in to risk, rather than the opposite.  This
> assumes the use of multiple namespaces, and is inapplicable if only one name
> is used. -- Darren Duncan

Can we agree on the new governance... first?

Then IF (and so far no one seems to have suggested plans for this)
there is ever a change that could cause instability or break backwards
compat or has any major risk, the voting policy can be enacted to work
out what the community wants, new name space for testing with a policy
of 6 month release before merging back into main or what ever it
maybe, but that is SEPARATE to the governance issue.

To me these are two separate issues and it would be good to close off
the governance issue before moving onto detail of how to run the
project.

Thanks

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] IMPORTANT: A discussion of DBIC governance and future development

[Dave Howorth]

On 2016-10-24 10:01, Peter Mottram wrote:

On 24/10/16 00:11, Darren Duncan wrote:

On 2016-10-23 3:04 PM, Karen Etheridge wrote:

 > I also like the idea of default dbic being the stable one, and the
dbic2
being opt in. +1

I don't see how it could credibly be the other way. There is no way
to get
informed consent from all the existing DBIx::Class users to ensure
that they
understand they are getting bleeding-edge code. Moving to a more risky
configuration must always be done intentionally.


Those are my thoughts exactly.  If DBIC ever started using multiple
namespaces to distinguish LTS from bigger changes, the LTS should
always have the existing name.  Users should always get the "safe"
option by default and explicitly opt-in to risk, rather than the
opposite.  This assumes the use of multiple namespaces, and is
inapplicable if only one name is used. -- Darren Duncan


If having two name spaces makes everyone happy and there are people
available to work on both then +1 from me as long as the existing
namespace is the more conservative one.


Does using two name spaces give any more security than git branches?

Any developments should be created in a new branch and only folded in 
when everybody is happy, and with a back compatibility warranty.


Or are people proposing that the project is permanently forked?

Oh, and are there any volunteers to maintain the stable name space, if 
there are to be two?


Cheers, 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] IMPORTANT: A discussion of DBIC governance and future development

[Peter Mottram]

On 24/10/16 00:11, Darren Duncan wrote:
> On 2016-10-23 3:04 PM, Karen Etheridge wrote:
>>  > I also like the idea of default dbic being the stable one, and the
>> dbic2
>> being opt in. +1
>>
>> I don't see how it could credibly be the other way. There is no way
>> to get
>> informed consent from all the existing DBIx::Class users to ensure
>> that they
>> understand they are getting bleeding-edge code. Moving to a more risky
>> configuration must always be done intentionally.
>
> Those are my thoughts exactly.  If DBIC ever started using multiple
> namespaces to distinguish LTS from bigger changes, the LTS should
> always have the existing name.  Users should always get the "safe"
> option by default and explicitly opt-in to risk, rather than the
> opposite.  This assumes the use of multiple namespaces, and is
> inapplicable if only one name is used. -- Darren Duncan
>
If having two name spaces makes everyone happy and there are people
available to work on both then +1 from me as long as the existing
namespace is the more conservative one.


___
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] IMPORTANT: A discussion of DBIC governance and future development

[Darren Duncan]

On 2016-10-23 3:04 PM, Karen Etheridge wrote:

 > I also like the idea of default dbic being the stable one, and the dbic2
being opt in. +1

I don't see how it could credibly be the other way. There is no way to get
informed consent from all the existing DBIx::Class users to ensure that they
understand they are getting bleeding-edge code. Moving to a more risky
configuration must always be done intentionally.


Those are my thoughts exactly.  If DBIC ever started using multiple namespaces 
to distinguish LTS from bigger changes, the LTS should always have the existing 
name.  Users should always get the "safe" option by default and explicitly 
opt-in to risk, rather than the opposite.  This assumes the use of multiple 
namespaces, and is inapplicable if only one name is used. -- 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] IMPORTANT: A discussion of DBIC governance and future development

[Darren Duncan]

On 2016-10-23 1:55 PM, Christian Walde wrote:

On Sun, 23 Oct 2016 22:19:42 +0200, Andrew Beverley  wrote:


- Riba was prepared to keep maintaining (and "tightening" in slower
time) "DBIC"


As far as i understood there was no circumstance under which he'd have been
involved further, at all. His plan, as far as i saw it stated, was to remove all
other accesses and hand FIRSTCOME over to an unnamed successor who would handle
things.


AFAIK, Riba said he would be available to answer technical questions by whomever 
takes on the DBIC management, and that AFAIK this hasn't changed. -- 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] IMPORTANT: A discussion of DBIC governance and future development

[fREW Schmidt]

I also like the idea of default dbic being the stable one, and the dbic2
being opt in. +1

-- 
sent from a rotary phone, pardon my brevity

On Oct 23, 2016 1:21 PM, "Andrew Beverley"  wrote:

> On Wed, 5 Oct 2016 04:07:04 -0400 David Golden  wrote:
> [...]
> > * DBIx::Class (DBIC) – Peter's work provides a capstone, with only bug
> > fixes thereafter
> > * DBIx::Class2 (DBIC2) – new feature development, with lower stability
> > expectations
> >
> > Some of the benefits I could see from this:
> >
> > (1) It helps DBIC users avoid getting upgraded past a stability point
> > without having to learn to pin module versions or change application
> > code to use a different package name.  People have to positively
> > opt-in for some risk in exchange for new features by asking for DBIC2
> > explicitly.
> >
> > (2) The relation between the two is more immediately obvious than
> > between, say, DBIx::Class::Stable and DBIx::Class.  It also seems
> > more like one project than two, particularly if both are under the
> > same governance, use the same mailing list, etc.
> >
> > (3) It sets a possible path forward of DBIC2 evolving new features
> > for a while and then eventually moving into a bug-fix-only state
> > while the next generation of new features go into a future DBIC3.
> >
> > There is some precedent for "Foo" evolution going to "Foo2" such as
> > Dancer/Dancer2, Test/Test2, and probably others.  Those have bigger
> > disruptions from old to new than I imagine DBIC2 having (initial
> > release of DBI2 probably being a carbon copy of the final version of
> > DBIC), but at least its a naming pattern that people will recognize.
>
> I'm coming round to this idea. I was originally against it as I assumed
> that it would be little more than a version freeze with no ongoing
> maintenance, but given the more recent discussions, I wonder whether
> this might be the best solution, if:
>
> - Riba was prepared to keep maintaining (and "tightening" in slower
> time) "DBIC", with its current set of features, thereby making it a
> rock-solid module, still maintained, that can be used in critical
> applications which only need the current feature set.
>
> - the previously-proposed committee creates and maintains "DBIC2",
> which becomes almost a testing ground, production ready, but for those
> that want to live slightly closer to the edge.
>
> Longer term, code could be ported from DBIC2 into DBIC.
>
> 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
___
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] IMPORTANT: A discussion of DBIC governance and future development

[Christian Walde]

On Sun, 23 Oct 2016 22:19:42 +0200, Andrew Beverley   
wrote:



- Riba was prepared to keep maintaining (and "tightening" in slower
time) "DBIC"


As far as i understood there was no circumstance under which he'd have  
been involved further, at all. His plan, as far as i saw it stated, was to  
remove all other accesses and hand FIRSTCOME over to an unnamed successor  
who would handle things.


--
With regards,
Christian Walde

___
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] IMPORTANT: A discussion of DBIC governance and future development

[Matt S Trout]

On Sun, Oct 23, 2016 at 04:30:12PM -0400, Ashley Pond V wrote:
> I am of a similar mind. I want to have both code paths and this seems
> like the only way to do that.

I worry a lot about the costs to the ecosystem of split effort.

There's a lot of DBIx::Class::* out there,

On the other hand using the bundling trick to allow application developers
to say

  use DBIx::Class::LTS;

and get the normal DBIC namespaces could work very well, *if* you could
resource the backcompat oriented volunteer time required to maintain it.

That way a straight 'cpanm DBIx::Class' would continue to provide up to date
code, anybody who wants to wait-and-see can do so, and the ecosystem doesn't
get forced to fork.

It also strikes me that a 'use DBIx::Class::Current;' or something to have
a non-dev release of something we think still needs burning-in time might
also be interesting.

Right now though, personally, I'm more focused on rebuilding a team that
can manage to successfully manage a single DBIC codebase. I suspect that's
going to be quite enough challenge for the moment.

-- 
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] IMPORTANT: A discussion of DBIC governance and future development

[Ashley Pond V]

On Sun, Oct 23, 2016 at 4:19 PM, Andrew Beverley  wrote:
> On Wed, 5 Oct 2016 04:07:04 -0400 David Golden  wrote:
> [...]
>> * DBIx::Class (DBIC) – Peter's work provides a capstone, with only bug
>> fixes thereafter
>> * DBIx::Class2 (DBIC2) – new feature development, with lower stability
>> expectations
>>
>> Some of the benefits I could see from this:
>>
>> (1) It helps DBIC users avoid getting upgraded past a stability point
>> without having to learn to pin module versions or change application
>> code to use a different package name.  People have to positively
>> opt-in for some risk in exchange for new features by asking for DBIC2
>> explicitly.
>>
>> (2) The relation between the two is more immediately obvious than
>> between, say, DBIx::Class::Stable and DBIx::Class.  It also seems
>> more like one project than two, particularly if both are under the
>> same governance, use the same mailing list, etc.
>>
>> (3) It sets a possible path forward of DBIC2 evolving new features
>> for a while and then eventually moving into a bug-fix-only state
>> while the next generation of new features go into a future DBIC3.
>>
>> There is some precedent for "Foo" evolution going to "Foo2" such as
>> Dancer/Dancer2, Test/Test2, and probably others.  Those have bigger
>> disruptions from old to new than I imagine DBIC2 having (initial
>> release of DBI2 probably being a carbon copy of the final version of
>> DBIC), but at least its a naming pattern that people will recognize.
>
> I'm coming round to this idea. I was originally against it as I assumed
> that it would be little more than a version freeze with no ongoing
> maintenance, but given the more recent discussions, I wonder whether
> this might be the best solution, if:
>
> - Riba was prepared to keep maintaining (and "tightening" in slower
> time) "DBIC", with its current set of features, thereby making it a
> rock-solid module, still maintained, that can be used in critical
> applications which only need the current feature set.
>
> - the previously-proposed committee creates and maintains "DBIC2",
> which becomes almost a testing ground, production ready, but for those
> that want to live slightly closer to the edge.
>
> Longer term, code could be ported from DBIC2 into DBIC.

I am of a similar mind. I want to have both code paths and this seems
like the only way to do that.

___
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] IMPORTANT: A discussion of DBIC governance and future development

[Andrew Beverley]

On Wed, 5 Oct 2016 04:07:04 -0400 David Golden  wrote:
[...]
> * DBIx::Class (DBIC) – Peter's work provides a capstone, with only bug
> fixes thereafter
> * DBIx::Class2 (DBIC2) – new feature development, with lower stability
> expectations
> 
> Some of the benefits I could see from this:
> 
> (1) It helps DBIC users avoid getting upgraded past a stability point
> without having to learn to pin module versions or change application
> code to use a different package name.  People have to positively
> opt-in for some risk in exchange for new features by asking for DBIC2
> explicitly.
> 
> (2) The relation between the two is more immediately obvious than
> between, say, DBIx::Class::Stable and DBIx::Class.  It also seems
> more like one project than two, particularly if both are under the
> same governance, use the same mailing list, etc.
> 
> (3) It sets a possible path forward of DBIC2 evolving new features
> for a while and then eventually moving into a bug-fix-only state
> while the next generation of new features go into a future DBIC3.
> 
> There is some precedent for "Foo" evolution going to "Foo2" such as
> Dancer/Dancer2, Test/Test2, and probably others.  Those have bigger
> disruptions from old to new than I imagine DBIC2 having (initial
> release of DBI2 probably being a carbon copy of the final version of
> DBIC), but at least its a naming pattern that people will recognize.

I'm coming round to this idea. I was originally against it as I assumed
that it would be little more than a version freeze with no ongoing
maintenance, but given the more recent discussions, I wonder whether
this might be the best solution, if:

- Riba was prepared to keep maintaining (and "tightening" in slower
time) "DBIC", with its current set of features, thereby making it a
rock-solid module, still maintained, that can be used in critical
applications which only need the current feature set.

- the previously-proposed committee creates and maintains "DBIC2",
which becomes almost a testing ground, production ready, but for those
that want to live slightly closer to the edge.

Longer term, code could be ported from DBIC2 into DBIC.

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] IMPORTANT: A discussion of DBIC governance and future development

[Darren Duncan]

On 2016-10-12 12:14 AM, Hartmaier Alexander wrote:

On 2016-10-06 21:15, Darren Duncan wrote:

On 2016-10-06 8:43 AM, Matt S Trout wrote:

On Tue, Oct 04, 2016 at 08:17:49PM -0700, Darren Duncan wrote:

That would be good, also in light with how that sentence continues:

"I suspect what we need to try and achieve is to get DBIC a bit more
decentralised - have it be a specific framework build atop a
more-like-Plack-for-DB-stuff - but you already know that's what I
have in mind and we both already know it's going to be a big-ass job
and we'll see if it pans out or not."

My own near term planned contributions to DBIC are precisely what
you said above.  They would constitute a more-like-Plack-for-DB
ecosystem and in particular they should benefit DBIC by optimizing
it more for maintainability, so it is easier for others to add
features or make changes or otherwise just be more confident that it
works properly.  If things go as I hope, this should start to land
in about a month.



Isn't DBI 'Plack-for-DB'?


In a manner of speaking DBI is indeed a Plack-for-DB, and came first.

However, DBI was also designed 20 years ago and has, for various reasons 
including being a Mature project, solidified around particular design decisions 
and API limitations that would have been chosen differently had it been invented 
today.  I know from various talk over the years that many people including Tim 
Bunce agree with this view.


A reasonable analogy is that my Plack-for-DB is akin to Perl 6 where DBI is akin 
to Perl 5.


I will refrain from discussing further details here, doing so is off-topic for 
the thread.


I only brought up my plans in this thread since I thought it would inform a 
discussion about the future of DBIC and its ecosystem like SQL::Abstract for 
people to know that I have a concrete vision for (aspects of) it and people 
don't have to think no one has a vision.


-- 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] IMPORTANT: A discussion of DBIC governance and future development

[Hartmaier Alexander]

On 2016-10-06 21:15, Darren Duncan wrote:

On 2016-10-06 8:43 AM, Matt S Trout wrote:

On Tue, Oct 04, 2016 at 08:17:49PM -0700, Darren Duncan wrote:

That would be good, also in light with how that sentence continues:

"I suspect what we need to try and achieve is to get DBIC a bit more
decentralised - have it be a specific framework build atop a
more-like-Plack-for-DB-stuff - but you already know that's what I
have in mind and we both already know it's going to be a big-ass job
and we'll see if it pans out or not."

My own near term planned contributions to DBIC are precisely what
you said above.  They would constitute a more-like-Plack-for-DB
ecosystem and in particular they should benefit DBIC by optimizing
it more for maintainability, so it is easier for others to add
features or make changes or otherwise just be more confident that it
works properly.  If things go as I hope, this should start to land
in about a month.


I think anything that's in that sort of vicinity is likely to be a big
enough set of changes that it'll (a) need to wait until whatever new
administration we end up with is settled in (b) need a decent RFC
process
and advance discussion of the risk/reward trade-offs involved.

After all, when I say "big-ass job" I'm generally not kidding about
that,
and at this point it looks like it's not only going to be a big-ass job,
but a big-ass job we're going to have to conduct without the help of the
person I was relying on being the other half of the architecture team
for
it.

So, I mean, "cool" but also "this is going to need serious
discussion" and
especially "please don't get your hopes up about 'near term'".


Not to worry, and I agree.

The first version of the thing that I was intending to land in the
short term was only intended to be, on its own, classified as a green
field experiment or proof of concept.  It would NOT by any means be
intended for production as is.

Basically I am working on a Plack-for-DB as an independent project,
and I was going to use an experimental fork of DBIC (on GitHub) as an
initial test case by roughly replacing DBIC guts to use that project
while using the fact that DBIC's pristine automated test suite as a
validation that DBIC still behaves correctly with the changed internals.

The new administration of DBIC can then use this working proof of
concept in their discussions on how they want to formally evolve
DBIC.  My experiment would constitute an RFC for how would you like to
use my Plack-for-DB, or adapt its design, to implement DBIC features
that were long desired but not provided.

-- Darren Duncan

Isn't DBI 'Plack-for-DB'?



___
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




*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
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] IMPORTANT: A discussion of DBIC governance and future development

[David Golden]

On Fri, Oct 7, 2016 at 1:09 PM, Peter Rabbitson 
wrote:
> David, given the decisions the PAUSE admins are faced with (see below)
> encourage you to inquire for more info on individual points that seem
> unclear. I will answer such inquiries in individual subthreads.

Everything seems pretty clear and I think you've demonstrated the high
standards of care in your thorough, responsible approach to handing off
your institutional knowledge.

> * The plan of succession I formed in December 2015, and had not
> deviated from until this week, is presently null and void. It was
> an unusual arrangement, with critical pieces based on a combination
> of promises and assumptions. Recent events resulted in the invalidation
> of several such foundation points, and there is no possible way I myself
> could presently endorse it.

I find this very vague and would appreciate any additional information you
feel you can share.  I'm disappointed that we (both the community and the
PAUSE admins, in this context) never got to hear more details about your
plan than what I quoted in my original email of this thread.

In particular, whether part of the plan or not, I think the community would
benefit from hearing more detail on your thoughts for what a stable
"freeze" would look like – what kinds of things should be allowed or not
allowed to change, how to do QA, etc.  Particularly if there is a
possibility of the namespace branching into "stable" and "ongoing
development" parts (regardless of which side stays "DBIx::Class"), I think
your views on how the stable branch ought to be managed would be valuable
insight to whoever winds up managing it.

> [...] I have grave reservations about the specific (now) 4-member team
> outlined by Matt. The reservations are entirely technical and procedural
> in nature [...] I will elaborate on these reservations if necessary

As above, I think hearing your reservations and the rationale behind them
would be valuable input.  It's clear from the comments from the community
so far that stability (however defined) is important to many.  Your
thoughts on what would and wouldn't work will help shape the discussion of
future governance.

> [...] I do not think it would be right for me to try to be the
> captain that steers us out of this mess.

Understood.  As I've said before, if there are people inside or outside the
community that you think could continue to represent the "extreme
stability" point of view as part of future project governance, I think it
would benefit the community for you to see if they are interested in such a
role and to nominate/endorse them as a voice you respect in that way.

> my integrity ... simply will not allow me to click the necessary buttons.

I hear you.  I see no reason to make changes until the community has a full
chance to discuss its governance plans, but will let you know before I
exercise administrative power to "click the buttons" in your stead.

> * As a final point on "going forward": I am concerned that the "software
> stability" argument has been grossly micharacterized[sic]: it was
presented
> as a binary "does it lose data" argument, when for me the main question
has
> always been "is it opinionated / does it insist on usurping the end-users
> time".

I think this would be a wonderful topic for you to elaborate on.

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] IMPORTANT: A discussion of DBIC governance and future development

[Peter Rabbitson]

On 10/03/2016 10:37 PM, David Golden wrote:


For those who don't know me, I'm DAGOLDEN on CPAN and I've joined this
list in my capacity as a PAUSE  administrator.



This email is mainly addressed to the PAUSE admins, however I think the 
(hopefully) following discussion is best served remaining on this list.


There has been a massive amount of input. While I have not answered 
directly almost any of it, I assure you I have read and considered every 
single word that has been said.


Please keep in mind, that everything I say below is not destructive 
cynicism, but is done out of love and desperation and complete, 
uniquely-informed understanding of what is at stake.


Bringing this thread back towards the actionable, I am presenting a 
collection of statements and positions, without elaborating on the 
individual line items. David, given the decisions the PAUSE admins are 
faced with (see below) I encourage you to inquire for more info on 
individual points that seem unclear. I will answer such inquiries in 
individual subthreads.




=== On what is there / what was planned

* I just sent a new progress report [1], with what has been completed 
out of the initial plan outlined in December [2].


* The allegations of an undisclosed private branch many changes are 
entirely baseless, as indicated by the timestamps on the CI logs of the 
main repository [3], which can be correlated with my extensive progress 
reports [4]. There is *no other DBIC code* of mine which is in anything 
resembling a state of readiness, yet is withheld from the public.


* As it is not clear what the future of the namespace will be ( see 
below ), I am not sure if the remaining pieces are worth implementing in 
the first place. All of the work outlined in [2] was either done to fix 
borderline-intractable bugs, or to stabilize the current behaviors 
(often in a bugward-compatible manner). That is in stark contrast with 
some of the opinions expressed in this thread, and as such I would like 
to see more clarity on where this project is going, before proceeding 
further.


* The annotation of currently outstanding issues/branches mentioned in 
[2] has not yet begun. As long as there is a demand for them, I will 
provide at least the main highlights.


* Regardless of what happens (and whether there is reasonable demand to 
implementing anything extra), I intend to produce a general codebase 
walkthrough, hopefully ready by the start of November. While I don't 
want to hype it up, I intend for its level of detail to dwarf that of 
[5]. This has been in planning for quite some time and the tools needed 
to pull this off have been in development for a while as well.


* As part of the support structure for the (now void, see below) 
succession plan, I arranged a publicly logged IRC channel #askriba [6] 
with the intent of holding scheduled "office hours" as long as there is 
a demand for my institutional knowledge. This remains in place 
regardless of the outcome of anything below.




=== On what is and will happen

* I strongly disagree with the PAUSE admins interpretation of my 
ownership of this project, and I strongly believe a procedural 
overstepping has taken place. However, the triggered discussion 
indicates my leadership is not without controversy, and therefore as 
indicated earlier[7], I am forfeiting my right to select the next FIRSTCOME.


* I am in no way shape or form considering keeping the FIRSTCOME myself. 
All current events aside, it has been my decision to remove myself from 
the helm a very long time ago, in order to avoid dealing with the 
obvious conflict of interest ( more on this was articulated almost 2 
years ago in [8] )


* The plan of succession I formed in December 2015, and had not deviated 
from until this week, is presently null and void. It was an unusual 
arrangement, with critical pieces based on a combination of promises and 
assumptions. Recent events resulted in the invalidation of several such 
foundation points, and there is no possible way I myself could presently 
endorse it.


* Taking aside my strong misgivings on the effectiveness of 
FLOSS-leadership-groups as a whole, I have grave reservations about the 
specific (now) 4-member team outlined by Matt. The reservations are 
entirely technical and procedural in nature, and are completely detached 
from Matt's and mine 4+ years long interpersonal conflict. I will 
elaborate on these reservations if necessary, but see next point.


* As I have neither a functional nor a backup plan, I am requesting 
active arbitration from the PAUSE admins. That is - please collect 
whatever additional information is necessary, make a decision on the 
future leadership of this project, and take an administrative action to 
carry this decision out. As indicated in the first part of this email I 
pledge to make available all my knowledge and offer my full cooperation 
to steady the ship over the coming weeks but I do not think it 

Re: [Dbix-class] IMPORTANT: A discussion of DBIC governance and future development

[Matt S Trout]

My message was written solely to be a retraction of and apology for what
I felt was an unfounded accusation I'd inadvertantly made against you,
because I prefer to set the record straight when I make such a mistake.

-- 
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] IMPORTANT: A discussion of DBIC governance and future development

[Peter Rabbitson]

On 10/07/2016 03:08 AM, Matt S Trout wrote:

On Mon, Oct 03, 2016 at 11:32:18PM +0200, Peter Rabbitson wrote:

Given the discussion generated way more interest than I anticipated, at
this point I am pausing all activity ( both code and administrative
changes ), until at least the 8th of October. I want to give ample time
for all interested parties to state their thoughts.


To replace my earlier reply.

I said it seemed strange to me to cease development when it's obvious that
both the co-maints and the users would love to have your final work.

However, the emotional toll of this conversation has made it very hard for
me to write useful code in the meantime.

As such, please everybody take riba's waiting code-wise as being the same
focus issue, rather than an attempt to punish the user base for disagreeing
with him, and please also accept my apologies for even implying it might
have been anything else.



Matt,

I find the above extremely patronizing and condescending. I am an adult 
- I can speak for myself if it were necessary.


There is an important issue at stake. An issue that for me is based 
exclusively on a technical and procedural rift. I do have emotions 
attached to this, sure. But I am keeping them out of this discussion.


You know better than most the only reason I am walking away is because I 
can't self-fund the time required.


Your repeated suggestions that this is all about the "toll" and the 
"burnout" and whathaveyou are not factual, not constructive, and 
therefore not welcome.


Please stop re-focusing the conversation.


___
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] IMPORTANT: A discussion of DBIC governance and future development

[Matt S Trout]

On Mon, Oct 03, 2016 at 11:32:18PM +0200, Peter Rabbitson wrote:
> Given the discussion generated way more interest than I anticipated, at 
> this point I am pausing all activity ( both code and administrative 
> changes ), until at least the 8th of October. I want to give ample time 
> for all interested parties to state their thoughts.

To replace my earlier reply.

I said it seemed strange to me to cease development when it's obvious that
both the co-maints and the users would love to have your final work.

However, the emotional toll of this conversation has made it very hard for
me to write useful code in the meantime.

As such, please everybody take riba's waiting code-wise as being the same
focus issue, rather than an attempt to punish the user base for disagreeing
with him, and please also accept my apologies for even implying it might
have been anything else.

-- 
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] IMPORTANT: A discussion of DBIC governance and future development

[John SJ Anderson]

I’ve been watching this conversation unfold from the sidelines, and as an 
extremely infrequent user of DBIC (but highly interested Perl community member 
and sometimes Open Source community manager), I haven’t felt the need to 
participate before now — but I’m afraid there’s something that’s being 
overlooked a bit. To wit, the last five words of: 

> On Oct 3, 2016, at 14:32, Peter Rabbitson  wrote:
> 
> While the project does not have a bright future under my (now likely moot) 
> plan, 

Riba: I would still very much like to hear the details of your plan, including 
but not limited to who you were intending to pass FIRSTCOME perms to, and what 
you and/or their vision of the future of the project was going to look like. I 
think people have been reading between the lines of some of your emails and 
extrapolating from there, and I’m not at all convinced that the picture people 
have in their heads is accurate. The only way to get an accurate picture is for 
you to explain what your plan is. 

I think the basic plan Matt has outlined seems broadly reasonable (I would 
maybe quibble with a detail or two, but overall, it seems sound enough) — but 
that doesn’t mean it’s the _only_ possible reasonable plan. Given your long and 
careful stewardship of the project, I’d hate for you to leave without 
explaining your vision of the future of DBIC. By not explaining it, I think, 
you’re not fully and robustly discharging your final responsibilities to the 
project, in my opinion. 

And finally, ObThanksForAllYouveDone. I think, whether you fully realize it or 
not, you’ve had a huge impact not only directly on DBIC but also in 
demonstrating the type of care and attention to detail that’s needed when 
bearing the responsibility for something as widely used as DBIC. Cheers, and I 
look forward to buying you a beer or six when I next get the chance. 8^)

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@lists.scsys.co.uk

Re: [Dbix-class] IMPORTANT: A discussion of DBIC governance and future development

[Darren Duncan]

On 2016-10-06 8:43 AM, Matt S Trout wrote:

On Tue, Oct 04, 2016 at 08:17:49PM -0700, Darren Duncan wrote:

That would be good, also in light with how that sentence continues:

"I suspect what we need to try and achieve is to get DBIC a bit more
decentralised - have it be a specific framework build atop a
more-like-Plack-for-DB-stuff - but you already know that's what I
have in mind and we both already know it's going to be a big-ass job
and we'll see if it pans out or not."

My own near term planned contributions to DBIC are precisely what
you said above.  They would constitute a more-like-Plack-for-DB
ecosystem and in particular they should benefit DBIC by optimizing
it more for maintainability, so it is easier for others to add
features or make changes or otherwise just be more confident that it
works properly.  If things go as I hope, this should start to land
in about a month.


I think anything that's in that sort of vicinity is likely to be a big
enough set of changes that it'll (a) need to wait until whatever new
administration we end up with is settled in (b) need a decent RFC process
and advance discussion of the risk/reward trade-offs involved.

After all, when I say "big-ass job" I'm generally not kidding about that,
and at this point it looks like it's not only going to be a big-ass job,
but a big-ass job we're going to have to conduct without the help of the
person I was relying on being the other half of the architecture team for
it.

So, I mean, "cool" but also "this is going to need serious discussion" and
especially "please don't get your hopes up about 'near term'".


Not to worry, and I agree.

The first version of the thing that I was intending to land in the short term 
was only intended to be, on its own, classified as a green field experiment or 
proof of concept.  It would NOT by any means be intended for production as is.


Basically I am working on a Plack-for-DB as an independent project, and I was 
going to use an experimental fork of DBIC (on GitHub) as an initial test case by 
roughly replacing DBIC guts to use that project while using the fact that DBIC's 
pristine automated test suite as a validation that DBIC still behaves correctly 
with the changed internals.


The new administration of DBIC can then use this working proof of concept in 
their discussions on how they want to formally evolve DBIC.  My experiment would 
constitute an RFC for how would you like to use my Plack-for-DB, or adapt its 
design, to implement DBIC features that were long desired but not provided.


-- 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] IMPORTANT: A discussion of DBIC governance and future development

[Matt S Trout]

On Thu, Oct 06, 2016 at 12:24:59PM +0200, Hartmaier Alexander wrote:
> A big part was also his and mst's plan to use Data::Query in DBIx::Class
> which they seen to have abandoned without communicating it.

Not so much abandoned as I basically got locked out as well and entirely
lost motivation to keep working on it until that changed, but didn't want
to say so explicitly because I figured getting into a fight with riba over
it wasn't going to achieve anything useful.

On the upside, in the mean time I think I may have come up with a more
incremental approach that'll let us get the advantages piecemeal and with
much lower risk; but this is not the thread for me to explain that proposal
so I'll circle back around to it later when I've finished thinking it
through.

-- 
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] IMPORTANT: A discussion of DBIC governance and future development

[Matt S Trout]

On Tue, Oct 04, 2016 at 08:17:49PM -0700, Darren Duncan wrote:
> That would be good, also in light with how that sentence continues:
> 
> "I suspect what we need to try and achieve is to get DBIC a bit more
> decentralised - have it be a specific framework build atop a
> more-like-Plack-for-DB-stuff - but you already know that's what I
> have in mind and we both already know it's going to be a big-ass job
> and we'll see if it pans out or not."
> 
> My own near term planned contributions to DBIC are precisely what
> you said above.  They would constitute a more-like-Plack-for-DB
> ecosystem and in particular they should benefit DBIC by optimizing
> it more for maintainability, so it is easier for others to add
> features or make changes or otherwise just be more confident that it
> works properly.  If things go as I hope, this should start to land
> in about a month.

I think anything that's in that sort of vicinity is likely to be a big
enough set of changes that it'll (a) need to wait until whatever new
administration we end up with is settled in (b) need a decent RFC process
and advance discussion of the risk/reward trade-offs involved.

After all, when I say "big-ass job" I'm generally not kidding about that,
and at this point it looks like it's not only going to be a big-ass job,
but a big-ass job we're going to have to conduct without the help of the
person I was relying on being the other half of the architecture team for
it.

So, I mean, "cool" but also "this is going to need serious discussion" and
especially "please don't get your hopes up about 'near term'".

-- 
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] IMPORTANT: A discussion of DBIC governance and future development

[Hartmaier Alexander]

Sorry for replying  that late but I was away for two month and didn't
find the right words in the short peroids of time I had.

castaway let me quote her answer in the mail conversation between David
Golden and the current PAUSE maintainers of DBIC that preceded this one:


Having read the last few days messages, consider this me joining in..

Admittedly I haven't been following the DBIC ML / commits lately, for
at least a year.. This is mostly because its felt like

a) Nothing is allowed to be added/tweaked until specifically approved
by Riba, or until some other piece of work is finished which can only
be done by Riba.

b) I didn't want to add to all the more things that Riba had to do,
thus keeping quiet until some point became available that others could
join in, was reached.

This has been the case for what seems like waaay too long (years),
such that its easy to think "nobody else cares", various of us who've
cared and attempted to help out, have been shoved away, or ignored.

Personally, I'd like to have DBIC be more of a community project
again, with various people having ideas, implementing additions,
checking each others work, patching issues, testing etcetc.. While I
get that its depended on a fair bit, I don't think that means being
*perfect* to the exclusion of all experimentation. I don't think I've
come across other bits of CPAN, apart from maybe the ones in core,
that attempt to be as rigorous in their perfection. Really, if people
upgrade, and encounter an issue .. they can either downgrade and wait,
or pitch in and help (or pay someone to).. this is open source after all.

As for the issue at hand: Who owns the first-come isnt terribly
relevant, as long as they work with those of us who'd like to see DBIC
continue to evolve/improve, ideally several folks will have co-maint,
and some sort of minor org of releases happens. As yet it hasn't been
mentioned whether transfer of the first-come from Riba, would also
involve cancelling all the co-maints? (or did that happen and I missed
it?)

TL:DR - more community involvement, less micromanagement please

Jess Robinson / JROBINSON / castaway


That's almost exactly what I felt the last few years (wow, time really
flies lately..., didn't felt that long).

Especially a) hit me several times and prevented branches
(people/abraxxa in the git repo) from getting merged to master and released.

I was able to work on the datetime featues in frew's
DBIx::Class::Helper::ResultSet::DateMethods1 but other things that
belong into core, also agreed by ribasushi, didn't make it.

A big part was also his and mst's plan to use Data::Query in DBIx::Class
which they seen to have abandoned without communicating it.

The third and final reason for me to stop trying to contribute was the,
imho silly, dispute about versioning where I was arguing for finally
releasing a 1.0 version to make the stability of DBIx::Class clear.
Ribasushi wanted to delay that until his large refactoring was complete,
including the one to use Data::Query. If I remember correctly mst sided
which him, at least as far as not releasing a 1.0 version immediately
without any further work. My argument that this can become version 1.1,
1.5 or 2.0 as well when it's done was ignored. After a while I just gave
up as it seemed that ribasushis word has to be accepted without objection.

For most parts I'm perfectly happy with DBIC and don't *need* new or
changed features.

Some API methods would be nicer to get renamed which wasn't accepted
either for backcompat, despite the fact that it still wasn't 1.0 and
that ribasushi used API stability as a 1.0 release delay argument.

I'd also like more flexibility in regards to joins, e.g. to not have to
add a second relationship with join_type => 'left' but being able to do
that by use case in the search method call.

We also use RecursiveUpdate heavily though
HTML::FormHandler::Model::DBIC in one app and making its feature core
was and still is a long-time goal for me.

I wasn't able to help ribasushi in his quest for perfect DBIC internals
either as I didn't know any of the parts he was working on and he didn't
want to take the time to educate me on it.

Regarding the first-come situation: I guess the PAUSE admins will do the
right thing if they feel that the person ribasushi hands over his
first-come rights to abuses it.

One also very important detail wasn't discussed at all so far: git
repository rights!

As this mail is already long enough I'll stop here and write another one
if more comes to my mind.

Best regards, Alex

On 2016-10-06 10:50, Jess Robinson wrote:

On Tue, 04 Oct 2016 19:20:51 +0100, Peter Mottram 
wrote:


On 04/10/16 19:08, Matt S Trout wrote:

On Tue, Oct 04, 2016 at 12:49:49PM -0400, Ashley Pond V wrote:

I did say MST RFC:MUST be respected. :P This is only here because of
you. I was an early CDBI user and was there for the fights over its
direction and saw you as the voice of reason, patience, and vision.
Regardless 

Re: [Dbix-class] IMPORTANT: A discussion of DBIC governance and future development

[Andrew Beverley]

I've not got much to add that hasn't already said, except that my
current priority is stability and performance over feature improvements.

Other than that, I would like to publicly thank Ribasushi for the huge
amount of effort and dedication he has put into the project. Not
just the code commits, but also his fanatical support to the user base.
There are very few open source projects that provide that level of
support, even with a large team. You will be missed Riba.

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] IMPORTANT: A discussion of DBIC governance and future development

[Jess Robinson]

On Tue, 04 Oct 2016 19:20:51 +0100, Peter Mottram  wrote:


On 04/10/16 19:08, Matt S Trout wrote:

On Tue, Oct 04, 2016 at 12:49:49PM -0400, Ashley Pond V wrote:

I did say MST RFC:MUST be respected. :P This is only here because of
you. I was an early CDBI user and was there for the fights over its
direction and saw you as the voice of reason, patience, and vision.
Regardless of work done since, I see you as the owner. I was unaware
there was as much of a schism as there apparently is.

I don't know which approach is better. I feel the "permanent
development ban" you assert is misrepresenting the situation.

Well, I'm not sure how else I can interpret riba's call for a 'project
freeze', especially given that in

http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/012210.html

he appears to feel that the previous contributors attempting to continue
the project is "the worst possible direction, one I worked really hard  
to

save this codebase from."

My reading is more that this:

/> Really, if people upgrade, />/and encounter an issue .. they can  
either downgrade and wait, or pitch in />/and help (or pay someone to)..  
this is open source after all./


is not a viable option if the breakage causes data loss. Problems at the
data layer are simply unacceptable and can result in major financial
damage and people being fired. Some projects can afford to be much more
bleeding edge but I feel that DBIx::Class needs to be paranoid about
what is accepted in core. After all there are other options to allow
features to be added without touching core.




The above quote from me is the case with all code from CPAN.. like any  
code from the internet, if you're using it for things mission critical,  
you should do a test cycle with updates to new versions, and thus give  
yourself room to say "eek, new changes dont work for me, better not  
upgrade production".


I was not suggesting nor advocating that future changes might happen more  
randomly or without testing.. of course we'd like to keep a release cycle  
that releases test candidates to give people a chance to test etc. However  
nobody is perfect (not even Riba or MST), bugs will and do appear.


Without the community/users pitching in and testing/pointing out  
bugs/helping to resolve as I suggested, we'd have waaay more issues than  
we do.


A lot of the comments in this thread make me think its time for v9.. then  
folks with v8 can happily stagnate...


Jess


___
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] IMPORTANT: A discussion of DBIC governance and future development

[Louis Erickson]

> On Oct 5, 2016, at 5:28 AM, Lasse Makholm  wrote:
> On Wed, Oct 5, 2016 at 12:23 PM, Leo Lapworth  wrote:
>> 
>> Hi,
>> 
>> On 5 October 2016 at 10:44, Peter Rabbitson  wrote:
>>> On 10/05/2016 08:50 AM, Karen Etheridge wrote:
> 
> It is now much harder to advance either of these points.
 
 Why?
 
>>> Because now that you causally dropped an insinuation that a part of the work
>>> I put into DBIC itself was performed for material gain
>> 
>> I can't say I considered this for a moment when reading Karen's comment.
>> 
>> I would hope that anyone doing such great work as you did in an Open Source
>> project SHOULD have the opportunity to make some money by supporting
>> the companies that use it, but I only consider this now you mention
>> material gain.
>> 
>> I read Karen's comment as a validation of how important, not just to
>> casual users
>> but to businesses the work you have or are doing. This is a sign of a 
>> successful
>> project, not an issue in my mind.
> 
> I totally agree. Anyone who knows enough about DBIC (or open source
> software in general for that matter) to have read this thread, will
> know that your (Peter's) involvement in this project is infinitely
> more than just a cash-grab. Frankly, to me at least, that notion is
> ludicrous.
> 
> I too hail from a critical production environment relying on DBIC at
> its core. We've come to rely (and probably take for granted) the
> stability of DBIC and thus the expertise and diligence of its
> maintainer(s).
> 
> However, I too worry about DBIC becoming a one-man project. The idea
> of a core-team kind of setup, focused on stability sounds sensible to
> me. And I have no good reason to think it wouldn't work.

I'm in the same group as all of these.

This is hardly a hugely public discussion.  It is archived on the web, but 
unless you're looking for it, stray people probably won't read it.  There are 
unlikely to be many "casual readers" of this discussion to misunderstand.

A team member - even the team leader - doing a private contract for a business 
is normal and expected behavior.  No one who knows either Ribasushi or Karen 
would have thought for a moment that the changes requested would have been at 
the expense of the project as a whole or any kind of money grab or financial 
impropriety.  It's someone who wanted something specific to their needs, and 
was hiring the best person available to get it done.  That's really common in 
OSS.


___
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] IMPORTANT: A discussion of DBIC governance and future development

[Lasse Makholm]

On Wed, Oct 5, 2016 at 12:23 PM, Leo Lapworth  wrote:
>
> Hi,
>
> On 5 October 2016 at 10:44, Peter Rabbitson  wrote:
> > On 10/05/2016 08:50 AM, Karen Etheridge wrote:
> >>>
> >>> It is now much harder to advance either of these points.
> >>
> >> Why?
> >>
> > Because now that you causally dropped an insinuation that a part of the work
> > I put into DBIC itself was performed for material gain
>
> I can't say I considered this for a moment when reading Karen's comment.
>
> I would hope that anyone doing such great work as you did in an Open Source
> project SHOULD have the opportunity to make some money by supporting
> the companies that use it, but I only consider this now you mention
> material gain.
>
> I read Karen's comment as a validation of how important, not just to
> casual users
> but to businesses the work you have or are doing. This is a sign of a 
> successful
> project, not an issue in my mind.

I totally agree. Anyone who knows enough about DBIC (or open source
software in general for that matter) to have read this thread, will
know that your (Peter's) involvement in this project is infinitely
more than just a cash-grab. Frankly, to me at least, that notion is
ludicrous.

I too hail from a critical production environment relying on DBIC at
its core. We've come to rely (and probably take for granted) the
stability of DBIC and thus the expertise and diligence of its
maintainer(s).

However, I too worry about DBIC becoming a one-man project. The idea
of a core-team kind of setup, focused on stability sounds sensible to
me. And I have no good reason to think it wouldn't work.

/Lasse

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

___
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] IMPORTANT: A discussion of DBIC governance and future development

[Colin Newell]

On 5 October 2016 at 11:23, Leo Lapworth  wrote:
> Hi,
>
> On 5 October 2016 at 10:44, Peter Rabbitson  wrote:
>> On 10/05/2016 08:50 AM, Karen Etheridge wrote:

 It is now much harder to advance either of these points.
>>>
>>> Why?
>>>
>> Because now that you causally dropped an insinuation that a part of the work
>> I put into DBIC itself was performed for material gain
>
> I can't say I considered this for a moment when reading Karen's comment.
>
> I would hope that anyone doing such great work as you did in an Open Source
> project SHOULD have the opportunity to make some money by supporting
> the companies that use it, but I only consider this now you mention
> material gain.
>
> I read Karen's comment as a validation of how important, not just to
> casual users
> but to businesses the work you have or are doing. This is a sign of a 
> successful
> project, not an issue in my mind.
>
> Leo

Ditto.

___
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] IMPORTANT: A discussion of DBIC governance and future development

[Leo Lapworth]

Hi,

On 5 October 2016 at 10:44, Peter Rabbitson  wrote:
> On 10/05/2016 08:50 AM, Karen Etheridge wrote:
>>>
>>> It is now much harder to advance either of these points.
>>
>> Why?
>>
> Because now that you causally dropped an insinuation that a part of the work
> I put into DBIC itself was performed for material gain

I can't say I considered this for a moment when reading Karen's comment.

I would hope that anyone doing such great work as you did in an Open Source
project SHOULD have the opportunity to make some money by supporting
the companies that use it, but I only consider this now you mention
material gain.

I read Karen's comment as a validation of how important, not just to
casual users
but to businesses the work you have or are doing. This is a sign of a successful
project, not an issue in my mind.

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] IMPORTANT: A discussion of DBIC governance and future development

[Peter Rabbitson]

On 10/05/2016 08:50 AM, Karen Etheridge wrote:

It is now much harder to advance either of these points.


Why?



Because now that you causally dropped an insinuation that a part of the 
work I put into DBIC itself was performed for material gain, a casual 
reader could interpret this entire thread as "Ribasushi tried to 
strangle a CPAN project for his own profit". That would be despite the 
fact that the core of your ( very complex and multi-layered ) 
work-related issue is in a module outside of ( and discouraged by ) the 
DBIC project, and as such entirely outside of the scope of this discussion.


Given I have not placed a single line into *this* codebase with material 
gain in mind, and because it is very important to me to distance myself 
from the above implication, I essentially no longer can send you folks 
an invoice for the other only tangentially related bits.


I am certain it won't really change the outcome of your employer still 
getting what they wanted, given some of the pieces involved in fixing 
your problem moved along far enough that I can't not wrap this up, in 
light of my obligation to *other* users of the 
::ResultSet::RecursiveUpdate stack.


So TLDR: nothing affecting you directly, but your unsolicited (and 
unrelated to this thread) disclosure made the aftertaste of the entire 
thing beyond unpleasant.



___
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] IMPORTANT: A discussion of DBIC governance and future development

[Colin Newell]

On 5 October 2016 at 09:07, David Golden  wrote:
> * DBIx::Class2 (DBIC2) – new feature development, with lower stability
> expectations
>

The idea of a new project with lower stability expectations worries
me.  The idea of backwards compatibility and stability have been a
major part of our continued use of the library.  Code I wrote >5 years
ago still works unchanged with no problem, and I would be loath to
lose that.

That's not to say that I have anything against the DBIC2 idea.  I just
want to be clear on what kind of stability/compatibility expectations
we would have.  I'm know David doesn't mean that it would become a hot
mess, but I'd rather not chip away at the stability expectations.

It's not like DBIC never introduced bugs with new versions, they were
simply fixed fairly quickly when they occurred.  Having a freeze and
then a split sounds okay, except that I normally associate that with a
different direction, which isn't something I'd greatly like to see.
If it's purely for non technical reasons then fair enough.


Colin.

___
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] IMPORTANT: A discussion of DBIC governance and future development

[David Golden]

On Tue, Oct 4, 2016 at 4:35 PM, Christian Walde 
wrote:

> [Peter] preparing [his] feature-frozen-bugfix-only release in a different
> namespace; mst's plan being used in the DBIx::Class namespace.
>

Speaking for myself (not for PAUSE admins), I think it's worth considering
the opposite as well:

* DBIx::Class (DBIC) – Peter's work provides a capstone, with only bug
fixes thereafter
* DBIx::Class2 (DBIC2) – new feature development, with lower stability
expectations

Some of the benefits I could see from this:

(1) It helps DBIC users avoid getting upgraded past a stability point
without having to learn to pin module versions or change application code
to use a different package name.  People have to positively opt-in for some
risk in exchange for new features by asking for DBIC2 explicitly.

(2) The relation between the two is more immediately obvious than between,
say, DBIx::Class::Stable and DBIx::Class.  It also seems more like one
project than two, particularly if both are under the same governance, use
the same mailing list, etc.

(3) It sets a possible path forward of DBIC2 evolving new features for a
while and then eventually moving into a bug-fix-only state while the next
generation of new features go into a future DBIC3.

There is some precedent for "Foo" evolution going to "Foo2" such as
Dancer/Dancer2, Test/Test2, and probably others.  Those have bigger
disruptions from old to new than I imagine DBIC2 having (initial release of
DBI2 probably being a carbon copy of the final version of DBIC), but at
least its a naming pattern that people will recognize.

Sincerely,
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] IMPORTANT: A discussion of DBIC governance and future development

[Peter Rabbitson]

This is not a response to the entirety of your email, but just one 
particular bit.


On 10/05/2016 05:24 AM, Karen Etheridge wrote:


3) Since I had contracted Peter (via my employer) for particular patches
last
year, I didn't want to say or do anything that would distract him or disrupt
that work, or become a conflict of interest with it; see also (2).


This was a really inappropriate piece of information to drop in a public 
forum for two reasons:


1) that work has not yet been completed
2) I have not actually billed your employer for anything

It is now much harder to advance either of these points.


___
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] IMPORTANT: A discussion of DBIC governance and future development

[Karen Etheridge]

On Sun, Oct 2, 2016 at 4:31 AM, Peter Rabbitson  wrote:
> I again must stress that there has been a huge 9+ months "discussion
> period" during which nobody (besides mst) came forward expressing
> concerns regarding my plans.

I had a lot of things to say, but I find that others have covered most of
the
main points, and I don't think I can say anything to persuade Peter away
from
the things he has already decided.  So, I will address my comments to the
PAUSE
admins instead:

1) I didn't think we were in a discussion period; I thought we were in a
period
of waiting for Peter to decide that he'd made all the changes he still
wanted
to make, so he would hand off control so that others could start submitting
change proposals again.

2) Once Peter had announced he was going to unilaterally hand off permission
bits to someone else, the slow-motion train wreck had already begun, but
since
the rest of the process was moving slowly, there seemed no pressing need to
act
immediately. Indeed, the more we waited, the more slowly things seemed to
progress.

3) Since I had contracted Peter (via my employer) for particular patches
last
year, I didn't want to say or do anything that would distract him or disrupt
that work, or become a conflict of interest with it; see also (2).

4) The length of time of Peter's involvement in the project, and the
intensity
and exclusivity thereof, entitles him to the gratitude from and
appreciation of
the community; it does not entitle him to unilaterally decide its future
direction.

5) Opening up control of the project (in the sense of having authority to
decide what is committed to the mainline code branch and released) to a
larger
number of people is in the best interests of all users, so long as that
group
is technically competent to do so and respects the critical nature of this
code.  The natural starting point for this group is the set of users who
currently have PAUSE permissions [1]; I trust this group collectively to
decide
who they wish to add to the group.  They also may wish to add additional
users
who can push commits to git (we found this to work well with Moose), but it
would also be reasonable to keep that locked down to the core group for now.

[1] Current PAUSE permissions on DBIx::Class are:

ABRAXXA (Alexander Hartmaier)
ARODLAND (Andrew Rodland; hobbs)
FREW (Arthur Axel "fREW" Schmidt)
ILMARI (Dagfinn Ilmari Mannsåker)
JROBINSON (Jess Robinson; castaway)
MSTROUT (Matt Trout; mst)
RIBASUSHI (Peter Rabbitson)


- Karen Etheridge, et...@cpan.org


On Mon, Oct 3, 2016 at 1:37 PM, David Golden  wrote:

> Hello, DBIC community.
>
> I apologize in advance for the length of this email, but I urge everyone
> that uses DBIC to read it fully as it relates to the future of this
> important module.
>
> For those who don't know me, I'm DAGOLDEN on CPAN and I've joined this
> list in my capacity as a PAUSE  [1] administrator.
>
> For those on the list who aren't familiar with CPAN administration, PAUSE
> is the service that authors use to upload modules to CPAN.  Among other
> functions, it generates the index that maps modules names to downloadable
> tarballs – e.g. "DBIx::Class" to "RIBASUSHI/DBIx-Class-0.082840.tar.gz"
> on a CPAN mirror.
>
> PAUSE also maintains a permissions model
>  [2] for each module
> namespace with two levels: "primary maintainer" (also called "first come")
> and "co-maintainer" (aka "co-maint").  Primary maintainers can grant and
> revoke co-maint permissions.  Both levels can upload tarballs to PAUSE,
> triggering an update to the index.
>
> Over the past several weeks, I've been the PAUSE administrator selected to
> mediate a dispute over future disposition of primary permissions for the
> DBIx::Class namespace.
>
> The dispute was triggered by Peter Rabbitson's "Traffic pattern changes
> ahead"
> 
> [3] email to this list on September 6, in which he said:
>
> *I have also firmly selected who will be getting the DBIx::Class *
> *namespace first-come[2], the transfer of which will also happen *
> *somewhere around the end of September.*
>
> Because the identity of the new primary maintainer was neither disclosed
> nor discussed with Matt Trout (the founder of the DBIC project, current
> co-maintainer and also PAUSE administrator) or other co-maintainers,
> several private conversations between ensued between Matt, Peter and others
> about this declaration.
>
> On September 15, Peter notified PAUSE administrators via the
> modu...@perl.org mailing list of an "Upcoming PAUSE permissions dispute"
>  [4].
> Separately, Matt notified PAUSE administrators privately with his own
> concerns about a possible dispute (his email was later disclosed and I'll
> link to it later).
>
> On September 21, I privately emailed all DBIC 

Re: [Dbix-class] IMPORTANT: A discussion of DBIC governance and future development

[Darren Duncan]

On 2016-10-04 6:41 PM, Matt S Trout wrote:

Meanwhile:

Riba presents

https://web.archive.org/web/20161004214347/http://blogs.perl.org/users/peter_rabbitson/2013/07/crowdsourcing-self-confidence.html#comment-1129854

as a to-him unamnbiguous legitimisation of his first come, except that in
there my entire goal was to turn DBIx::Class into a team project again, which
if you read my comment will, I hope, be obvious.

As I said then: "I suspect what we need to try and achieve is to get DBIC a
bit more decentralised" - and I stand by that now, hence my proposal of a
core team.


That would be good, also in light with how that sentence continues:

"I suspect what we need to try and achieve is to get DBIC a bit more 
decentralised - have it be a specific framework build atop a 
more-like-Plack-for-DB-stuff - but you already know that's what I have in mind 
and we both already know it's going to be a big-ass job and we'll see if it pans 
out or not."


My own near term planned contributions to DBIC are precisely what you said 
above.  They would constitute a more-like-Plack-for-DB ecosystem and in 
particular they should benefit DBIC by optimizing it more for maintainability, 
so it is easier for others to add features or make changes or otherwise just be 
more confident that it works properly.  If things go as I hope, this should 
start to land in about a month.


-- 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] IMPORTANT: A discussion of DBIC governance and future development

[Matt S Trout]

Meanwhile:

Riba presents

https://web.archive.org/web/20161004214347/http://blogs.perl.org/users/peter_rabbitson/2013/07/crowdsourcing-self-confidence.html#comment-1129854

as a to-him unamnbiguous legitimisation of his first come, except that in
there my entire goal was to turn DBIx::Class into a team project again, which
if you read my comment will, I hope, be obvious.

As I said then: "I suspect what we need to try and achieve is to get DBIC a
bit more decentralised" - and I stand by that now, hence my proposal of a
core team.

I continue to be confused as to why ribasushi considers such pedantic points
of order more important than providing a future for DBIx::Class that the
user base can agree upon.

Subject: Re: Message from PAUSE Admins to DBIx::Class maintainers [resend]
To: Matt S Trout , Graham Knop ,
 David Golden , "modu...@perl.org" 

On 10/04/2016 11:36 PM, Matt S Trout wrote:
>
> Had I not got explicit agreement before transferring anything that all I
> was doing was easing co-maint addition, I would absolutely not have gone
> down this route.

Since we are digging in the past: had I not gotten an unambiguous 
legitimization of my 1st come from both Matt[1] and an even stronger one 
from David[2] ( in addition to a large swathe of the community ) I don't 
think I would have returned for additional 3 years trying to rescue this 
project from its immense architectural debt.

[1] 
https://web.archive.org/web/20161004214347/http://blogs.perl.org/users/peter_rabbitson/2013/07/crowdsourcing-self-confidence.html#comment-1129854
[2] 
https://web.archive.org/web/20161004214347/http://blogs.perl.org/users/peter_rabbitson/2013/07/crowdsourcing-self-confidence.html#comment-1130257


-- 
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] IMPORTANT: A discussion of DBIC governance and future development

[Louis Erickson]

Hello, all.

I don't talk here much, because of the excellent work done by the DBIC teams 
over the years.  I've read along and learned a lot, though, and used DBIC 
professionally.

First, thank you to mst, Ribasushi, and all the other contributors for their 
hard work in stabilizing DBIC and making it the robust, dependable, reliable 
thing it is today.  I know how much work that is, and am not sure anyone says 
that very often.  It is a really excellent piece of software which is a great 
contribution to the Perl community and the larger world.

I mean that; I work at a large hardware company you have probably heard of.  
Our hardware is used for, among other things, sequencing new treatments for 
cancer.  We couldn't build these massive chips without the build tools written 
in Perl and using DBIC.  You really are making the world as a whole a better 
place.

I'm sorry to see this dispute.  It's a sign that someone or several people in 
the community are deeply unhappy, and that something we all took for granted 
isn't working.  That's painful, and needs to be fixed.  I think Ribasushi's 
done the right thing by taking care of himself and starting the conversation to 
get out of this position.  That doesn't mean I think he should take his ball 
and go home, freezing the codebase and leaving everyone stuck, but that he 
needs to get himself out of something that's become untenable for him.

(more below...)

> On Oct 4, 2016, at 1:59 PM, Matt S Trout  wrote:
> On Tue, Oct 04, 2016 at 09:43:56PM +0100, Leo Lapworth wrote:
>> On 4 October 2016 at 21:35, Christian Walde  
>> wrote:
>>> 
>>> 

>>> You preparing your feature-frozen-bugfix-only release in a different
>>> namespace; mst's plan being used in the DBIx::Class namespace.
>>> 
>>> That way people who're worried can stick to a stable branch of dbic, and
>>> people who actually need more from DBIc at some point in the future aren't
>>> lost in limbo.
>>> 
>>> There's no need to deprive your stable-needing users of the work you had
>>> planned to do, nor your far future users of a useful library, if both can
>>> be served at the same time.
>> 
>> +1
> 
> Note that we have prior technical art for providing bundled versions of
> SQLA in dev releases which could absolutely be repurposed to allow for a
> 'use DBIx::Class::StabilityFreeze;' to work:
> 
> https://github.com/dbsrgits/dbix-class/blob/current/dq/lib/DBIx/Class/_TempExtlib.pm
> 
> (idea the result of discussion between riba and I, implemented by riba)


Is this really needed?

For our mission critical systems, we have versioning in place.  We don't move 
ahead until we've passed our acceptance tests.  DBIC is not usually an issue, 
but many Perl modules can be, and once you're protecting one, protecting them 
all is as easy as protecting one of them.  There are excellent tools out there 
to help with this, Pinto, Stratopan, perlbrew, etc.  This is not a new problem, 
and there are good solutions for it.

As long as DBIC tries to keep the release stable, and fixes user-facing issues 
quickly, the people who need it can move ahead when they're ready to, and be 
completely able to work.  Just like we do with Test::More, core Perl versions, 
and all the other modules we depend on.

I feel mst's proposed solution will keep the codebase stable, and let it remain 
vital and under development.  The risk is there, and the team approving and 
code-reviewing changes understands that.  Lots of testing and care, with good 
code-review will manage that risk, while allowing future development.  A 
closed-off DBIC just forces extra work onto all the users to migrate to the 
inevitable fork, for no concrete benefit.

Please don't lock DBIC down.


___
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] IMPORTANT: A discussion of DBIC governance and future development

[Matt S Trout]

On Tue, Oct 04, 2016 at 09:43:56PM +0100, Leo Lapworth wrote:
> On 4 October 2016 at 21:35, Christian Walde  wrote:
> > On Mon, 03 Oct 2016 23:32:18 +0200, rabbit+dbic at  wrote:
> >
> >> Nevertheless, if nobody else finds this problematic: I will step aside
> >> and let an eager community, inadvertently suppressed all these years,
> >> steer this project further.
> >
> >
> > Honestly, if anything i'd love to see a solution that offends everyone
> > equally.
> >
> > You preparing your feature-frozen-bugfix-only release in a different
> > namespace; mst's plan being used in the DBIx::Class namespace.
> >
> > That way people who're worried can stick to a stable branch of dbic, and
> > people who actually need more from DBIc at some point in the future aren't
> > lost in limbo.
> >
> > There's no need to deprive your stable-needing users of the work you had
> > planned to do, nor your far future users of a useful library, if both can
> > be served at the same time.
> 
> +1

Note that we have prior technical art for providing bundled versions of
SQLA in dev releases which could absolutely be repurposed to allow for a
'use DBIx::Class::StabilityFreeze;' to work:

https://github.com/dbsrgits/dbix-class/blob/current/dq/lib/DBIx/Class/_TempExtlib.pm

(idea the result of discussion between riba and I, implemented by riba)

-- 
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] IMPORTANT: A discussion of DBIC governance and future development

[Leo Lapworth]

On 4 October 2016 at 21:35, Christian Walde  wrote:
> On Mon, 03 Oct 2016 23:32:18 +0200, rabbit+dbic at  wrote:
>
>> Nevertheless, if nobody else finds this problematic: I will step aside
>> and let an eager community, inadvertently suppressed all these years,
>> steer this project further.
>
>
> Honestly, if anything i'd love to see a solution that offends everyone
> equally.
>
> You preparing your feature-frozen-bugfix-only release in a different
> namespace; mst's plan being used in the DBIx::Class namespace.
>
> That way people who're worried can stick to a stable branch of dbic, and
> people who actually need more from DBIc at some point in the future aren't
> lost in limbo.
>
> There's no need to deprive your stable-needing users of the work you had
> planned to do, nor your far future users of a useful library, if both can
> be served at the same time.

+1

Leo (Ranguard)

___
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] IMPORTANT: A discussion of DBIC governance and future development

[Aaron Crane]

Peter Mottram  wrote:
> DBIx::Class has gained a reputation for being a solid piece of
> infrastructure which can be trusted and ribasushi has been instrumental
> in getting it to that point. Care must be taken to ensure that this
> expectation of reliability is not lost in favour of feature bloat and
> risky code.

I definitely agree that Riba's hard work to ensure reliability has
been extremely effective. But it's also the case that DBIC had an
impressive record of reliability long before he took over
maintainership, and I think we shouldn't lose sight of that simple
fact.

Nobody is suggesting that the project become a free-for-all of risky
features. But I do find it very difficult to see how we, the users of
DBIC, would be well served by the project being changed in a way that
bans all future changes other than trivial bug fixes — and that does
seem to be the model that's been proposed.

-- 
Aaron Crane ** http://aaroncrane.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] IMPORTANT: A discussion of DBIC governance and future development

[Matt S Trout]

On Tue, Oct 04, 2016 at 08:20:51PM +0200, Peter Mottram wrote:
> On 04/10/16 19:08, Matt S Trout wrote:
> > On Tue, Oct 04, 2016 at 12:49:49PM -0400, Ashley Pond V wrote:
> >> I did say MST RFC:MUST be respected. :P This is only here because of
> >> you. I was an early CDBI user and was there for the fights over its
> >> direction and saw you as the voice of reason, patience, and vision.
> >> Regardless of work done since, I see you as the owner. I was unaware
> >> there was as much of a schism as there apparently is.
> >>
> >> I don't know which approach is better. I feel the "permanent
> >> development ban" you assert is misrepresenting the situation.
> > Well, I'm not sure how else I can interpret riba's call for a 'project
> > freeze', especially given that in
> >
> > http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/012210.html
> >
> > he appears to feel that the previous contributors attempting to continue
> > the project is "the worst possible direction, one I worked really hard to
> > save this codebase from."
> My reading is more that this:
> 
> /> Really, if people upgrade, />/and encounter an issue .. they can either 
> downgrade and wait, or pitch in />/and help (or pay someone to).. this is 
> open source after all./
> 
> is not a viable option if the breakage causes data loss.

Please do remember that I'm the one who originally started a stable release
cycle, with vast attention to compatibility issues, because the idea of
damaging somebody's production data scares the crap out of me.

In fact, the only reason ribasushi became chainsaw delegate was because for
the first time I'd found somebody I trusted to be as worried about the
potential for data loss as I was.

> Some projects can afford to be much more
> bleeding edge but I feel that DBIx::Class needs to be paranoid about
> what is accepted in core. After all there are other options to allow
> features to be added without touching core.

The policy of DBIx::Class, as originally set by me, has always been that if
it can be done outside of core, it should be done outside of core.

I'm not sure what sort of cowboy future you're imagining but it certainly
isn't what any of the contributors signed up for, or what any of us have in
mind.

-- 
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] IMPORTANT: A discussion of DBIC governance and future development

[Peter Mottram]

On 04/10/16 19:08, Matt S Trout wrote:
> On Tue, Oct 04, 2016 at 12:49:49PM -0400, Ashley Pond V wrote:
>> I did say MST RFC:MUST be respected. :P This is only here because of
>> you. I was an early CDBI user and was there for the fights over its
>> direction and saw you as the voice of reason, patience, and vision.
>> Regardless of work done since, I see you as the owner. I was unaware
>> there was as much of a schism as there apparently is.
>>
>> I don't know which approach is better. I feel the "permanent
>> development ban" you assert is misrepresenting the situation.
> Well, I'm not sure how else I can interpret riba's call for a 'project
> freeze', especially given that in
>
> http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/012210.html
>
> he appears to feel that the previous contributors attempting to continue
> the project is "the worst possible direction, one I worked really hard to
> save this codebase from."
My reading is more that this:

/> Really, if people upgrade, />/and encounter an issue .. they can either 
downgrade and wait, or pitch in />/and help (or pay someone to).. this is open 
source after all./

is not a viable option if the breakage causes data loss. Problems at the
data layer are simply unacceptable and can result in major financial
damage and people being fired. Some projects can afford to be much more
bleeding edge but I feel that DBIx::Class needs to be paranoid about
what is accepted in core. After all there are other options to allow
features to be added without touching core.

DBIx::Class has gained a reputation for being a solid piece of
infrastructure which can be trusted and ribasushi has been instrumental
in getting it to that point. Care must be taken to ensure that this
expectation of reliability is not lost in favour of feature bloat and
risky code.

R.
PeteM


___
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] IMPORTANT: A discussion of DBIC governance and future development

[Matt S Trout]

On Tue, Oct 04, 2016 at 12:49:49PM -0400, Ashley Pond V wrote:
> I did say MST RFC:MUST be respected. :P This is only here because of
> you. I was an early CDBI user and was there for the fights over its
> direction and saw you as the voice of reason, patience, and vision.
> Regardless of work done since, I see you as the owner. I was unaware
> there was as much of a schism as there apparently is.
> 
> I don't know which approach is better. I feel the "permanent
> development ban" you assert is misrepresenting the situation.

Well, I'm not sure how else I can interpret riba's call for a 'project
freeze', especially given that in

http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/012210.html

he appears to feel that the previous contributors attempting to continue
the project is "the worst possible direction, one I worked really hard to
save this codebase from."

Of course, it would help if he'd elaborate on his plan; so far, sadly,
he's expended a lot more words explaining why his future plans for
DBIx::Class aren't the contributors' or users' business than he has
explaining what said plans actually are. Hopefully that will change.

-- 
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] IMPORTANT: A discussion of DBIC governance and future development

[David Golden]

As I mentioned, I think it would be great to understand what Peter is
thinking about a "freeze" – whether that's no new releases ever, or
security/critical-bug-fix releases only, general bug fixes only, or
something else.

I think it would be perfectly reasonable for people to say "we want
stability more than new features, so yes to bug fixes, but no to new
features".

I also think it would be perfectly reasonable for people to say they want
new features, even if it risks introducing new bugs. And then people can
debate how much risk to accept and what development processes might
mitigate it.

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] IMPORTANT: A discussion of DBIC governance and future development

[Ashley Pond V]

I did say MST RFC:MUST be respected. :P This is only here because of
you. I was an early CDBI user and was there for the fights over its
direction and saw you as the voice of reason, patience, and vision.
Regardless of work done since, I see you as the owner. I was unaware
there was as much of a schism as there apparently is.

I don't know which approach is better. I feel the "permanent
development ban" you assert is misrepresenting the situation. I
haven't done any dev work here for years though so my opinion must be
heavily salted to be palatable. You speak of this situation killing
DBIC. I thought it was dying for a bit there a few years back and even
started exploring doing my own version. DBIC feels more vital now than
it had for quite some time. On the other hand, maybe it could
experience another renaissance if the gates reopen to more and easier
development.

So, I don't know. I do think it should be solved between lead devs
(past and present). There is apparently too much the peanut gallery
doesn't know and this is a practical not a theoretical discussion so
only those involved have truly valid opinions.

___
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] IMPORTANT: A discussion of DBIC governance and future development

[Matt S Trout]

On Tue, Oct 04, 2016 at 11:21:36AM +0100, Pedro Melo wrote:
> Hi,
> 
> On 4/10/16 1:15 AM, "Ashley Pond V"  wrote:
> >My view: MST must be respected but I personally defer to RIBASUSHI and
> >his judgement. I say, what he says, goes. He has earned the benefit of
> >the doubt. At least until it can be clearly demonstrated the approach
> >is harming the code base should that ever become the case.
> 
> +1, I could not have written this better.

Given ribasushi's plan is "end all feature development because nobody else
can be trusted to add features without potentially introducing bugs", I'm
not sure how one could 'demonstrate harm' - freezing it and never adding
any features again is unlikely to *harm* the code base, merely kill the
project.

I mean, he's absolutely right that anybody else will, at this point,
be more likely to introduce bugs in the process of continuing development,
but if you read castaway's and ilmari's comments here:

http://www.nntp.perl.org/group/perl.modules/2016/10/msg96192.html
http://www.nntp.perl.org/group/perl.modules/2016/10/msg96191.html

that's at least partially because we've been effectively locked out of
contributing to the codebase for a couple years now, and all development
has been basically done without the discussion that would help us understand
the implementation as well as the goals.

I mean, if you genuinely believe ribasushi's right, and nobody else in the
world is competent to add features to DBIx::Class ever again, then fair
enough, let's start planning the funeral. But I can't see how that's the
best possible outcome here for the userbase as a whole.

-- 
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] IMPORTANT: A discussion of DBIC governance and future development

[Pedro Melo]

Hi,

On 4/10/16 1:15 AM, "Ashley Pond V"  wrote:

>RIBASUSHI has given this codebase a tremendous amount of care,
>improvement, and deft effort. I am a user and evangelist of DBIC since
>it was the first fork of CDBI that started to solve so many problems.
>Peter has solved many problems since.
>
>My view: MST must be respected but I personally defer to RIBASUSHI and
>his judgement. I say, what he says, goes. He has earned the benefit of
>the doubt. At least until it can be clearly demonstrated the approach
>is harming the code base should that ever become the case.

+1, I could not have written this better.

Bye,

>
>­Ashley
>
>On Mon, Oct 3, 2016 at 6:09 PM, Darren Duncan 
>wrote:
>> Peter,
>>
>> Regardless of what else happens, I very much would look forward to you
>> finishing up and shipping all the code changes you spent the last year
>> working on.  It sounds like you're almost done them, and I don't want
>>all
>> that effort to go to waste.
>>
>> I trust you that this work would provide an island of stability of
>>sorts,
>> and a version that people can continue to use for the extended term
>>whether
>> others choose to just maintain that or choose to make major changes of
>>their
>> own, your stable version would still be there as a useful legacy.
>>
>> Given that your remaining time is limited, I request that you don't
>>halt on
>> the code until the 8th as mentioned, unless you need to rest anyway,
>>and use
>> the time you have to try and finish what you started and leave a better
>> legacy.
>>
>> Thank you for all your effort over the last years.
>>
>> -- Darren Duncan
>>
>>
>> On 2016-10-03 2:32 PM, Peter Rabbitson wrote:
>>>
>>> On 10/03/2016 10:37 PM, David Golden wrote:


 

 In the ensuing discussion, Peter disclosed additional details about
his
 plans for the future of DBIC
>>>
>>>
>>> Given the discussion generated way more interest than I anticipated, at
>>> this
>>> point I am pausing all activity ( both code and administrative changes
>>>),
>>> until
>>> at least the 8th of October. I want to give ample time for all
>>>interested
>>> parties to state their thoughts.
>>>
>>>  From my side, in order to highlight the main "point of contention" if
>>>you
>>> will,
>>> I am pulling together several pieces from the aforementioned threads:
>>>
 How much more concerning, then, to discover in the last few days
 that you have seen your DBIC-related activities since December as
 effectively winding up the project, rather than preparing to leave
 it to others.
 ...
 I know a bunch of the the pending changes are not ready to merge (or
 "sub-par" if you will); this is because I haven't had the motivation
to
 put more work into them
 ...
 I suspect if we managed to get all of the branches
 people had planned that were delayed because riba's response to the
 proposed
 features was "yes, but please wait for me to finish X first" done then
 that
 work in itself might be a major release's worth.
 ...
 While I get that its (n.b. DBIC) depended on a fair bit, I don't think
 that
 means being  *perfect* to the exclusion of all experimentation. I
don't
 think
 I've come across other bits of CPAN, apart from maybe the ones in
core,
 that
 attempt  to be as rigorous in their perfection. Really, if people
 upgrade,
 and  encounter an issue .. they can either downgrade and wait, or
pitch
 in
 and  help (or pay someone to).. this is open source after all.
>>>
>>>
>>> While the project does not have a bright future under my (now likely
>>>moot)
>>> plan,
>>> the approach indicated above is, in my opinion, the worst possible
>>> direction,
>>> one I worked really hard to save this codebase from.
>>>
>>> Nevertheless, if nobody else finds this problematic: I will step aside
>>>and
>>> let
>>> an eager community, inadvertently suppressed all these years, steer
>>>this
>>> project
>>> further.
>>>
>>> Regards
>>> RIBASUSHI
>>
>>
>>
>> ___
>> 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



___
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] IMPORTANT: A discussion of DBIC governance and future development

[Ashley Pond V]

RIBASUSHI has given this codebase a tremendous amount of care,
improvement, and deft effort. I am a user and evangelist of DBIC since
it was the first fork of CDBI that started to solve so many problems.
Peter has solved many problems since.

My view: MST must be respected but I personally defer to RIBASUSHI and
his judgement. I say, what he says, goes. He has earned the benefit of
the doubt. At least until it can be clearly demonstrated the approach
is harming the code base should that ever become the case.

–Ashley

On Mon, Oct 3, 2016 at 6:09 PM, Darren Duncan  wrote:
> Peter,
>
> Regardless of what else happens, I very much would look forward to you
> finishing up and shipping all the code changes you spent the last year
> working on.  It sounds like you're almost done them, and I don't want all
> that effort to go to waste.
>
> I trust you that this work would provide an island of stability of sorts,
> and a version that people can continue to use for the extended term whether
> others choose to just maintain that or choose to make major changes of their
> own, your stable version would still be there as a useful legacy.
>
> Given that your remaining time is limited, I request that you don't halt on
> the code until the 8th as mentioned, unless you need to rest anyway, and use
> the time you have to try and finish what you started and leave a better
> legacy.
>
> Thank you for all your effort over the last years.
>
> -- Darren Duncan
>
>
> On 2016-10-03 2:32 PM, Peter Rabbitson wrote:
>>
>> On 10/03/2016 10:37 PM, David Golden wrote:
>>>
>>>
>>> 
>>>
>>> In the ensuing discussion, Peter disclosed additional details about his
>>> plans for the future of DBIC
>>
>>
>> Given the discussion generated way more interest than I anticipated, at
>> this
>> point I am pausing all activity ( both code and administrative changes ),
>> until
>> at least the 8th of October. I want to give ample time for all interested
>> parties to state their thoughts.
>>
>>  From my side, in order to highlight the main "point of contention" if you
>> will,
>> I am pulling together several pieces from the aforementioned threads:
>>
>>> How much more concerning, then, to discover in the last few days
>>> that you have seen your DBIC-related activities since December as
>>> effectively winding up the project, rather than preparing to leave
>>> it to others.
>>> ...
>>> I know a bunch of the the pending changes are not ready to merge (or
>>> "sub-par" if you will); this is because I haven't had the motivation to
>>> put more work into them
>>> ...
>>> I suspect if we managed to get all of the branches
>>> people had planned that were delayed because riba's response to the
>>> proposed
>>> features was "yes, but please wait for me to finish X first" done then
>>> that
>>> work in itself might be a major release's worth.
>>> ...
>>> While I get that its (n.b. DBIC) depended on a fair bit, I don't think
>>> that
>>> means being  *perfect* to the exclusion of all experimentation. I don't
>>> think
>>> I've come across other bits of CPAN, apart from maybe the ones in core,
>>> that
>>> attempt  to be as rigorous in their perfection. Really, if people
>>> upgrade,
>>> and  encounter an issue .. they can either downgrade and wait, or pitch
>>> in
>>> and  help (or pay someone to).. this is open source after all.
>>
>>
>> While the project does not have a bright future under my (now likely moot)
>> plan,
>> the approach indicated above is, in my opinion, the worst possible
>> direction,
>> one I worked really hard to save this codebase from.
>>
>> Nevertheless, if nobody else finds this problematic: I will step aside and
>> let
>> an eager community, inadvertently suppressed all these years, steer this
>> project
>> further.
>>
>> Regards
>> RIBASUSHI
>
>
>
> ___
> 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] IMPORTANT: A discussion of DBIC governance and future development

[Darren Duncan]

Peter,

Regardless of what else happens, I very much would look forward to you finishing 
up and shipping all the code changes you spent the last year working on.  It 
sounds like you're almost done them, and I don't want all that effort to go to 
waste.


I trust you that this work would provide an island of stability of sorts, and a 
version that people can continue to use for the extended term whether others 
choose to just maintain that or choose to make major changes of their own, your 
stable version would still be there as a useful legacy.


Given that your remaining time is limited, I request that you don't halt on the 
code until the 8th as mentioned, unless you need to rest anyway, and use the 
time you have to try and finish what you started and leave a better legacy.


Thank you for all your effort over the last years.

-- Darren Duncan

On 2016-10-03 2:32 PM, Peter Rabbitson wrote:

On 10/03/2016 10:37 PM, David Golden wrote:




In the ensuing discussion, Peter disclosed additional details about his
plans for the future of DBIC


Given the discussion generated way more interest than I anticipated, at this
point I am pausing all activity ( both code and administrative changes ), until
at least the 8th of October. I want to give ample time for all interested
parties to state their thoughts.

 From my side, in order to highlight the main "point of contention" if you will,
I am pulling together several pieces from the aforementioned threads:


How much more concerning, then, to discover in the last few days
that you have seen your DBIC-related activities since December as
effectively winding up the project, rather than preparing to leave
it to others.
...
I know a bunch of the the pending changes are not ready to merge (or
"sub-par" if you will); this is because I haven't had the motivation to
put more work into them
...
I suspect if we managed to get all of the branches
people had planned that were delayed because riba's response to the proposed
features was "yes, but please wait for me to finish X first" done then that
work in itself might be a major release's worth.
...
While I get that its (n.b. DBIC) depended on a fair bit, I don't think that
means being  *perfect* to the exclusion of all experimentation. I don't think
I've come across other bits of CPAN, apart from maybe the ones in core, that
attempt  to be as rigorous in their perfection. Really, if people upgrade,
and  encounter an issue .. they can either downgrade and wait, or pitch in
and  help (or pay someone to).. this is open source after all.


While the project does not have a bright future under my (now likely moot) plan,
the approach indicated above is, in my opinion, the worst possible direction,
one I worked really hard to save this codebase from.

Nevertheless, if nobody else finds this problematic: I will step aside and let
an eager community, inadvertently suppressed all these years, steer this project
further.

Regards
RIBASUSHI



___
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] IMPORTANT: A discussion of DBIC governance and future development

[Frank Carnovale]

Thanks for raising this David.

I prefer the "Bazaar" over the "Cathedral".

Cathedrals are fabulously impressive places of important historical
interest, but they become cold and abandoned.  If you need to do day-to-day
business you go to the bazaar, where latest gadgets for every taste can be
found.

I'm the author of DBIx::Class::Schema::Loader::Dynamic.  I hope I won't
have to move that (imho essential) module to some different namespace.




On 3 October 2016 at 21:37, David Golden  wrote:

> Hello, DBIC community.
>
> I apologize in advance for the length of this email, but I urge everyone
> that uses DBIC to read it fully as it relates to the future of this
> important module.
>
> For those who don't know me, I'm DAGOLDEN on CPAN and I've joined this
> list in my capacity as a PAUSE  [1] administrator.
>
> For those on the list who aren't familiar with CPAN administration, PAUSE
> is the service that authors use to upload modules to CPAN.  Among other
> functions, it generates the index that maps modules names to downloadable
> tarballs – e.g. "DBIx::Class" to "RIBASUSHI/DBIx-Class-0.082840.tar.gz"
> on a CPAN mirror.
>
> PAUSE also maintains a permissions model
>  [2] for each module
> namespace with two levels: "primary maintainer" (also called "first come")
> and "co-maintainer" (aka "co-maint").  Primary maintainers can grant and
> revoke co-maint permissions.  Both levels can upload tarballs to PAUSE,
> triggering an update to the index.
>
> Over the past several weeks, I've been the PAUSE administrator selected to
> mediate a dispute over future disposition of primary permissions for the
> DBIx::Class namespace.
>
> The dispute was triggered by Peter Rabbitson's "Traffic pattern changes
> ahead"
> 
> [3] email to this list on September 6, in which he said:
>
> *I have also firmly selected who will be getting the DBIx::Class *
> *namespace first-come[2], the transfer of which will also happen *
> *somewhere around the end of September.*
>
> Because the identity of the new primary maintainer was neither disclosed
> nor discussed with Matt Trout (the founder of the DBIC project, current
> co-maintainer and also PAUSE administrator) or other co-maintainers,
> several private conversations between ensued between Matt, Peter and others
> about this declaration.
>
> On September 15, Peter notified PAUSE administrators via the
> modu...@perl.org mailing list of an "Upcoming PAUSE permissions dispute"
>  [4].
> Separately, Matt notified PAUSE administrators privately with his own
> concerns about a possible dispute (his email was later disclosed and I'll
> link to it later).
>
> On September 21, I privately emailed all DBIC maintainers (CPAN authors
> ABRAXXA, ARODLAND, FREW, ILMARI, JROBINSON, MSTROUT, and RIBASUSHI) on
> behalf of PAUSE administrators with our collective view of how this dispute
> would be best resolved.  Peter asked that any discussion be public, so I
> reposted it to the modu...@perl.org mailing list as "Message from PAUSE
> Admins to DBIx::Class maintainers [resend]"
>  [5]
>
> I urge everyone to read that thread in full as well.  For reference, it
> includes a copy
>  [6]
> of Matt's previously private email to PAUSE administrators.
>
> Importantly, the thread summarizes PAUSE administrators' position on the
> dispute, which I repost verbatim here:
>
> *(1) Given the importance of DBIC to the broader Perl community (i.e. way*
> *"upriver"  >), we’d like to*
> *see a more open discussion between existing maintainers about what
> happens*
> *next in terms of DBIC leadership and control of primary permissions.*
>
> *(2) The best outcome from our perspective would be for a successor to be*
> *decided by consensus of existing maintainers.*
>
> *(3) Given a dispute among maintainers, the only outcome that is
> absolutely*
> *unacceptable to PAUSE admins would be a unilateral permissions transfer*
> *decision.*
>
> *(4) We really hope the DBIC maintainers and/or community can resolve this*
> *internally.*
>
> In the ensuing discussion, Peter disclosed additional details about his
> plans for the future of DBIC in the "Future plans" section of this email
>  [7]:
>
> *I am still planning to wrap up the remaining pieces, including some *
> *unannounced initiatives to get the project into the best shape possible *
> *to survive its leaderlessness.*
>
> *I am still planning to remove all co-maint perms and handover the *
> *first-come to a yet-undisclosed person. Given no clear 

Re: [Dbix-class] IMPORTANT: A discussion of DBIC governance and future development

[Peter Rabbitson]

On 10/03/2016 10:37 PM, David Golden wrote:




In the ensuing discussion, Peter disclosed additional details about his
plans for the future of DBIC


Given the discussion generated way more interest than I anticipated, at 
this point I am pausing all activity ( both code and administrative 
changes ), until at least the 8th of October. I want to give ample time 
for all interested parties to state their thoughts.


From my side, in order to highlight the main "point of contention" if 
you will, I am pulling together several pieces from the aforementioned 
threads:



How much more concerning, then, to discover in the last few days
that you have seen your DBIC-related activities since December as
effectively winding up the project, rather than preparing to leave
it to others.
...
I know a bunch of the the pending changes are not ready to merge (or
"sub-par" if you will); this is because I haven't had the motivation to
put more work into them
...
I suspect if we managed to get all of the branches
people had planned that were delayed because riba's response to the proposed
features was "yes, but please wait for me to finish X first" done then that
work in itself might be a major release's worth.
...
While I get that its (n.b. DBIC) depended on a fair bit, I don't think that
means being  *perfect* to the exclusion of all experimentation. I don't think
I've come across other bits of CPAN, apart from maybe the ones in core, that
attempt  to be as rigorous in their perfection. Really, if people upgrade,
and  encounter an issue .. they can either downgrade and wait, or pitch in
and  help (or pay someone to).. this is open source after all.


While the project does not have a bright future under my (now likely 
moot) plan, the approach indicated above is, in my opinion, the worst 
possible direction, one I worked really hard to save this codebase from.


Nevertheless, if nobody else finds this problematic: I will step aside 
and let an eager community, inadvertently suppressed all these years, 
steer this project further.


Regards
RIBASUSHI

___
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