IMPORTANT: A discussion of DBIC governance and future development

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
119 messages Options
1 ... 3456
Reply | Threaded
Open this post in threaded view
|

Re: IMPORTANT: A discussion of DBIC governance and future development

Ashley Pond V
On Sun, Oct 23, 2016 at 4:19 PM, Andrew Beverley <[hidden email]> wrote:

> On Wed, 5 Oct 2016 04:07:04 -0400 David Golden <[hidden email]> 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@...
Reply | Threaded
Open this post in threaded view
|

Re: IMPORTANT: A discussion of DBIC governance and future development

Matt S Trout-2
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@...
Reply | Threaded
Open this post in threaded view
|

Re: IMPORTANT: A discussion of DBIC governance and future development

Christian Walde
In reply to this post by Andrew Beverley
On Sun, 23 Oct 2016 22:19:42 +0200, Andrew Beverley <[hidden email]>  
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@...
Reply | Threaded
Open this post in threaded view
|

Re: IMPORTANT: A discussion of DBIC governance and future development

fREW Schmidt
In reply to this post by Andrew Beverley

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" <[hidden email]> wrote:
On Wed, 5 Oct 2016 04:07:04 -0400 David Golden <[hidden email]> 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@...

_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@...
Reply | Threaded
Open this post in threaded view
|

Re: IMPORTANT: A discussion of DBIC governance and future development

Karen Etheridge
> 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.

On Sun, Oct 23, 2016 at 3:00 PM, fREW Schmidt <[hidden email]> wrote:

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" <[hidden email]> wrote:
On Wed, 5 Oct 2016 04:07:04 -0400 David Golden <[hidden email]> 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@...

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


_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@...
Reply | Threaded
Open this post in threaded view
|

Re: IMPORTANT: A discussion of DBIC governance and future development

Darren Duncan
In reply to this post by Christian Walde
On 2016-10-23 1:55 PM, Christian Walde wrote:
> On Sun, 23 Oct 2016 22:19:42 +0200, Andrew Beverley <[hidden email]> 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@...
Reply | Threaded
Open this post in threaded view
|

Re: IMPORTANT: A discussion of DBIC governance and future development

Darren Duncan
In reply to this post by Karen Etheridge
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@...
Reply | Threaded
Open this post in threaded view
|

Re: 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@...
Reply | Threaded
Open this post in threaded view
|

Re: 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@...
Reply | Threaded
Open this post in threaded view
|

Re: IMPORTANT: A discussion of DBIC governance and future development

Leo Lapworth
In reply to this post by David Golden
On 23 October 2016 at 23:11, Darren Duncan <[hidden email]> 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@...
Reply | Threaded
Open this post in threaded view
|

Clarification on the split-namespace proposal

Peter Rabbitson-2
In reply to this post by Christian Walde
On 10/23/2016 10:55 PM, Christian Walde wrote:
> On Sun, 23 Oct 2016 22:19:42 +0200, Andrew Beverley <[hidden email]>
> 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.

The situation has changed. Notably I have taken up employment where (all
current plans considered) I will have to maintain at minimum a private
fork of DBIx::Class for my own use.

In light of several proposals on the list, the gist of my *revised*
position is:


- If there is sufficient interest in myself continuing to be the sole
gatekeeper/point of responsibility for the DBIx::Class distribution

   and

- Folks are not concerned with neither my tangibly limited availability
going forward (I started a 40h/week job), nor with the potential
conflict of interest (i.e. that I might slip up and put $work concerns
ahead of the userbase)

   and

- All current comaints are content with relinquishing their claims to
the namespace and continuing building up on my work outside of the
DBIx::Class distribution


Then, yes: I suppose you can consider this a proposal to avail myself to
keeping the preexisting actual setup unchanged for the foreseeable future.


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@...
Reply | Threaded
Open this post in threaded view
|

Re: Clarification on the split-namespace proposal

Leo Lapworth
On 24 October 2016 at 12:20, Peter Rabbitson <[hidden email]> wrote:

> On 10/23/2016 10:55 PM, Christian Walde wrote:
>>
>> On Sun, 23 Oct 2016 22:19:42 +0200, Andrew Beverley <[hidden email]>
>> 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.
>
>
> The situation has changed. Notably I have taken up employment where (all
> current plans considered) I will have to maintain at minimum a private fork
> of DBIx::Class for my own use.

Sounds like a bad position to start from, you should introduce the company
to standards and working with CPAN, it's a great place where people
can work together to achieve a standard set of tools so we don't all
have to relearn every module when we start a new job.

> In light of several proposals on the list, the gist of my *revised* position
> is:
>
>
> - If there is sufficient interest in myself continuing to be the sole
> gatekeeper/point of responsibility for the DBIx::Class distribution
>
>   and
>
> - Folks are not concerned with neither my tangibly limited availability
> going forward (I started a 40h/week job), nor with the potential conflict of
> interest (i.e. that I might slip up and put $work concerns ahead of the
> userbase)

Isn't this the argument you put against a community effort, where
people might put new features ahead of stability?

This sounds like the worst of all options.

I'd rather such a key project as DBIx::Class was managed by a team of people,
dedicated to stability and clarity of process, not a single point of failure or
opinion.

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@...
Reply | Threaded
Open this post in threaded view
|

Re: Clarification on the split-namespace proposal

Andrew Beverley
On Mon, 24 Oct 2016 13:40:15 +0100 Leo Lapworth <[hidden email]> wrote:
> This sounds like the worst of all options.

I disagree. Given the last 3 weeks of discussions, it sounds like the
only option, and the one that offers a solution for everyone.

> I'd rather such a key project as DBIx::Class was managed by a team of
> people, dedicated to stability and clarity of process, not a single
> point of failure or opinion.

In which case you opt for DBIx::Class2.

Personally, I'd probably use DBIC for some projects and DBIC2 for
others. Choice (and to some degree competition) is rarely a bad thing
in open source.

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@...
Reply | Threaded
Open this post in threaded view
|

Re: IMPORTANT: A discussion of DBIC governance and future development

James E Keenan
In reply to this post by Leo Lapworth
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@...
Reply | Threaded
Open this post in threaded view
|

Re: 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@...
Reply | Threaded
Open this post in threaded view
|

Re: Clarification on the split-namespace proposal

Christian Walde
In reply to this post by Peter Rabbitson-2
On Mon, 24 Oct 2016 13:20:27 +0200, Peter Rabbitson  
<[hidden email]> wrote:

> On 10/23/2016 10:55 PM, Christian Walde wrote:
>> On Sun, 23 Oct 2016 22:19:42 +0200, Andrew Beverley <[hidden email]>
>> 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.
>
> The situation has changed. Notably I have taken up employment where (all  
> current plans considered) I will have to maintain at minimum a private  
> fork of DBIx::Class for my own use.
>
> In light of several proposals on the list, the gist of my *revised*  
> position is:
>
>
> - If there is sufficient interest in myself continuing to be the sole  
> gatekeeper/point of responsibility for the DBIx::Class distribution
>
>    and
>
> - Folks are not concerned with neither my tangibly limited availability  
> going forward (I started a 40h/week job), nor with the potential  
> conflict of interest (i.e. that I might slip up and put $work concerns  
> ahead of the userbase)
>
>    and
>
> - All current comaints are content with relinquishing their claims to  
> the namespace and continuing building up on my work outside of the  
> DBIx::Class distribution
>
>
> Then, yes: I suppose you can consider this a proposal to avail myself to  
> keeping the preexisting actual setup unchanged for the foreseeable  
> future.

I was conflicted about this. But the more i think about this i lean  
against it.

The main thing i want is to retain a development speed that keeps it  
healthy enough to keep living on. Below a certain level of development  
activity it will die because it won't be able to keep up with the world  
changing around it, and dbic won't die gracefully either.

I'd love to see you stay involved if only because you're currently the one  
person with the most intimate knowledge about DBIc.

On the other hand there is absolutely no guarantee as to the kind of  
development speed there will be with you, other than "low".

Additionally, given that you, as per comments you made to me, see it as  
your duty as an engineer to use every tool at your disposal to do what you  
consider best for the engineering integrity of the software at hand.  
You've made it sufficiently clear that you consider it the best for DBIc  
to freeze, with at most emergency patches applied. Given the fact that  
you've in the past proven that you will stop at nothing to achieve what  
you consider necessary, i see no other choice other than to weigh into  
every consideration i bring to this the fact that you may still be trying  
to achieve your original goal.

Next, this feels like an extortion attempt to me. Whereas before it was a  
clear "You don't like me anymore, so you won't get the toys i was planning  
to make." it is now "I'll be making my own toys as well, but unless you  
play by my rules only, you don't get to play with my toys."

You've also made no attempt to assure us that your further involvement  
will resolve currently existing deadlocks ("wait until my branch is done")  
for other contributors.

I know that going with the new governance and a team consisting mainly of  
the developers of modules DBIc depends on is a bit of a gamble. How much  
time will they actually find to contribute? What traps will they run into  
due to not having your level of knowledge?

But weighing that up against all the aforementioned, and the fact that  
your proposal would further tighten things to a single point of failure i  
feel better with the gamble. Particularly since the proposed governance  
structure does not preclude your further involvement at all, be it with  
you being a contributor, or be it with you part of the core team

--
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@...
Reply | Threaded
Open this post in threaded view
|

Re: Clarification on the split-namespace proposal

Matthew Phillips
Christian,
I don't believe it is fair at all to attribute malice to Peter in this situation. He's mentioned multiple times throughout this process that although he wants what he thinks is best, that the reason he's reached out is to let the user base decide.

Regarding your desire for active development and it being more likely with a joint team, I can only point to a quote from Frew from a mail chain on the perl.modules list:
"I am content with Riba's plan, though am skeptical he could find a person
living who can replace him.  Not to offend the various people who could,
but the combination of intelligence, caution, and knowledge of the project
itself, and motivation is going to be hard to pass along, though I'd love
to be proven wrong.
 Not to be overly negative but I also don't think what any of us do about
this will make a difference. I will be astounded if there is another major
DBIC release in the year after ribasushi leaves. That gives the community
and pause admins plenty of time to act after the fact."
The majority of the conversations that have taken place under the operating assumption that he no longer has the will or time to continue his role, and will be stepping down. With his newfound employment involving DBIC this has changed his situation, but for reasons he has outlined it is very difficult to continue his work unless it is under his terms.

So, given a choice between a proven quantity, and an unproven (and in Frew and I's opinion almost non-existent) quantity, it seems like the obvious choice for Peter to continue. The gratitude expressed for Peter's immense amount of work over the past few years from the users (and me) during these past few weeks points to this. 

Cheers,
Matt

On Tuesday, October 25, 2016, Christian Walde <[hidden email]> wrote:
On Mon, 24 Oct 2016 13:20:27 +0200, Peter Rabbitson <[hidden email]> wrote:

On 10/23/2016 10:55 PM, Christian Walde wrote:
On Sun, 23 Oct 2016 22:19:42 +0200, Andrew Beverley <[hidden email]>
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.

The situation has changed. Notably I have taken up employment where (all current plans considered) I will have to maintain at minimum a private fork of DBIx::Class for my own use.

In light of several proposals on the list, the gist of my *revised* position is:


- If there is sufficient interest in myself continuing to be the sole gatekeeper/point of responsibility for the DBIx::Class distribution

   and

- Folks are not concerned with neither my tangibly limited availability going forward (I started a 40h/week job), nor with the potential conflict of interest (i.e. that I might slip up and put $work concerns ahead of the userbase)

   and

- All current comaints are content with relinquishing their claims to the namespace and continuing building up on my work outside of the DBIx::Class distribution


Then, yes: I suppose you can consider this a proposal to avail myself to keeping the preexisting actual setup unchanged for the foreseeable future.

I was conflicted about this. But the more i think about this i lean against it.

The main thing i want is to retain a development speed that keeps it healthy enough to keep living on. Below a certain level of development activity it will die because it won't be able to keep up with the world changing around it, and dbic won't die gracefully either.

I'd love to see you stay involved if only because you're currently the one person with the most intimate knowledge about DBIc.

On the other hand there is absolutely no guarantee as to the kind of development speed there will be with you, other than "low".

Additionally, given that you, as per comments you made to me, see it as your duty as an engineer to use every tool at your disposal to do what you consider best for the engineering integrity of the software at hand. You've made it sufficiently clear that you consider it the best for DBIc to freeze, with at most emergency patches applied. Given the fact that you've in the past proven that you will stop at nothing to achieve what you consider necessary, i see no other choice other than to weigh into every consideration i bring to this the fact that you may still be trying to achieve your original goal.

Next, this feels like an extortion attempt to me. Whereas before it was a clear "You don't like me anymore, so you won't get the toys i was planning to make." it is now "I'll be making my own toys as well, but unless you play by my rules only, you don't get to play with my toys."

You've also made no attempt to assure us that your further involvement will resolve currently existing deadlocks ("wait until my branch is done") for other contributors.

I know that going with the new governance and a team consisting mainly of the developers of modules DBIc depends on is a bit of a gamble. How much time will they actually find to contribute? What traps will they run into due to not having your level of knowledge?

But weighing that up against all the aforementioned, and the fact that your proposal would further tighten things to a single point of failure i feel better with the gamble. Particularly since the proposed governance structure does not preclude your further involvement at all, be it with you being a contributor, or be it with you part of the core team

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

_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@...
Reply | Threaded
Open this post in threaded view
|

Re: Clarification on the split-namespace proposal

Charlie Garrison
Good morning,

On 27 Oct 2016, at 0:50, Matthew Phillips wrote:

> So, given a choice between a proven quantity, and an unproven (and in
> Frew and I's opinion almost  non-existent) quantity, it seems like
> the obvious choice for Peter to continue. The gratitude expressed for
> Peter's immense amount of work over the past few years from the users
> (and me) during these past few weeks points to this. 

Thanks Matt. That’s what I’ve been thinking during this conversation
but wasn’t sure how to express it.

+1 Peter

Charlie
--

    Charlie Garrison  <[hidden email]>
    github.com/cngarrison   metacpan.org/author/CNG

_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@...
Reply | Threaded
Open this post in threaded view
|

Re: Clarification on the split-namespace proposal

Renvoize, Martin

+1 from me too, well expressed Matt.

I also wanted to add that it really feels to me like people are only focused on the negatives of a split. Reduced resources.  That simply isn't the case here, we're left with a solid dbic with a commitment from riba to continue supporting it, all be with a reduction in hours.  We then have a second project with the new found freedom to break api's and trial new features with a group of excited coders wanting to jump in.

Martin


On 26 Oct 2016 9:20 p.m., "Charlie Garrison" <[hidden email]> wrote:
Good morning,

On 27 Oct 2016, at 0:50, Matthew Phillips wrote:

So, given a choice between a proven quantity, and an unproven (and in Frew and I's opinion almost  non-existent) quantity, it seems like the obvious choice for Peter to continue. The gratitude expressed for Peter's immense amount of work over the past few years from the users (and me) during these past few weeks points to this. 

Thanks Matt. That’s what I’ve been thinking during this conversation but wasn’t sure how to express it.

+1 Peter

Charlie
--

   Charlie Garrison  <[hidden email]>
   github.com/cngarrison   metacpan.org/author/CNG

_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@...

_______________________________________________
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@...
1 ... 3456