Re: [Dbix-class] A slightly more concrete proposal

[David Golden]

On Sat, Oct 8, 2016 at 5:33 PM, Peter Rabbitson  wrote:
>> Given that Peter abdicated the right to choose first-come himself
>
> This is not the case. The right was taken away from me, in an unprecedented
> overreach by the PAUSE admins, as summarized by Graham Knop in
> http://www.nntp.perl.org/group/perl.modules/2016/10/msg96217.html

I will repeat the language previously used: a unilateral transfer was
unacceptable.

I can understand how Peter might interpret that as a "right taken
away".  However, management of a namespace is not a right.  It is a
privilege delegated by PAUSE administrators to CPAN authors following
certain rules and historical conventions.  (Quite literally, it is
permission to modify certain database tables in PAUSE.)

Further, Peter's prior agreement with Matt at the time of the initial
transfer calls into question whether Peter can, in fact, claim an
exclusive, unilateral privilege to name a successor.

If there is something unprecedented in this situation, it is Peter's
agreement to – and subsequent repudiation of – a permissions transfer
agreement that included a "takeback" clause.

Given Peter's claim that his subsequent work gives him moral authority
to repudiate the agreement, we believe that the community is in the
best position to assess such a claim and ultimately to guide the
future of DBIC.  We are pleased with the engagement to date.

Peter certainly is allowed to propose a successor (either his original
choice or an alternative) and we have repeatedly encouraged him to do
so.  Peter is also an important figure in the project and his voice
should be valued in the selection of new governance and a roadmap for
the future.

If he chooses not to name a successor or participate in discussions
for personal reasons, that is up to him and we encourage people to
respect his boundaries.

Regards,
David

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

Re: [Dbix-class] A slightly more concrete proposal

[Darren Duncan]

On 2016-10-08 2:33 PM, Peter Rabbitson wrote:

I have been battling a severe cold, and can't manage to write sufficiently clear
prose. I hope to have David's questions addressed by Monday

However I need to unambiguously address the following right now:

On 10/08/2016 09:33 PM, Darren Duncan wrote:

Given that Peter abdicated the right to choose first-come himself


This is not the case. The right was taken away from me, in an unprecedented
overreach by the PAUSE admins, as summarized by Graham Knop in
http://www.nntp.perl.org/group/perl.modules/2016/10/msg96217.html

I am really unhappy that me choosing to not fight for my rights is seen as
abdication, instead of being an attempt to prevent the project suffering more
damage than it already has.


Peter, by "abdication" I am specifically talking about this comment of yours, 
where you say "I am forfeiting my right to select the next FIRSTCOME".


On 2016-10-07 10:09 AM, Peter Rabbitson wrote:

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


But as it seems this isn't the meaning you intended, I retract the comment you 
quoted.



Darren, I understand you are really enthusiastic and have many plans for the
future, but the forcefulness of your latest messages is becoming a distraction
from what is at stake here. Please take a step back and let me address the
questions David has raised.


I apologize that my latest messages have come across as being too forceful and 
that they distract you.


I will do as you say, step back and wait before speaking further.

-- 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] A slightly more concrete proposal

[Peter Rabbitson]

I have been battling a severe cold, and can't manage to write 
sufficiently clear prose. I hope to have David's questions addressed by 
Monday


However I need to unambiguously address the following right now:

On 10/08/2016 09:33 PM, Darren Duncan wrote:

Given that Peter abdicated the right to choose first-come himself


This is not the case. The right was taken away from me, in an 
unprecedented overreach by the PAUSE admins, as summarized by Graham 
Knop in http://www.nntp.perl.org/group/perl.modules/2016/10/msg96217.html


I am really unhappy that me choosing to not fight for my rights is seen 
as abdication, instead of being an attempt to prevent the project 
suffering more damage than it already has.


Darren, I understand you are really enthusiastic and have many plans for 
the future, but the forcefulness of your latest messages is becoming a 
distraction from what is at stake here. Please take a step back and let 
me address the questions David has raised.



___
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] A slightly more concrete proposal

[Darren Duncan]

On 2016-10-08 7:07 AM, Matt S Trout wrote:

I stand by the
statement that if whoever riba picked comes forward themselves, I'll happily
add their name to my proposal, but if not, I think you lot are going to have
to figure out a way to pick one yourselves, since the whole point of this
slot is to provide a brake on the rest of us.


I, for one, strongly encourage the successor that Peter Rabbitson picked to come 
forward on their own and volunteer their identity.


As this person was hand-picked and has already agreed to do the job of 
stewarding DBIC, they must have an interest in the future of DBIC and want to 
see things done well by it.


Given that Peter abdicated the right to choose first-come himself, I also 
interpret this as that he would be ok with his chosen replacement stepping up on 
their own and announcing themselves, he isn't pushing the button, and making 
their own public offer or proposal to steward the project.


Please speak-up, whomever you are, I think everyone would be happy for you to be 
involved.


Speaking up is not an obligation for you to take the job later, you can still be 
free to continue being involved or change your mind.


But this would help address the elephant in the room, the unknown person 
element.

Thank you in advance.

-- 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] A slightly more concrete proposal

[David Golden]

On Sat, Oct 8, 2016 at 10:07 AM, Matt S Trout  wrote:

> (3) [snip] Please
> please everybody remember this is a vague draft, you're allowed to propose
> adjustments yourselves, oh and if somebody has a plan they think is better
> then write it up and propose it - if nothing else, a second plan will
> provide for concrete comparisons to refine this one rather than it being
> passed through by default.
>
> (4) Same statement as 3, but with an added point: You don't need to have me
> back either. [snip]

I also want to add that if anyone isn't comfortable replying to the
list with feedback – or is prohibited from replying because of company
confidentiality restrictions – I'm happy to receive private emails and
your feedback will be treated confidentially.  Please just mention
DBIC in the subject line so it stands out in my inbox.

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] A slightly more concrete proposal

[Matt S Trout]

On Tue, Oct 04, 2016 at 08:17:08PM +, Matt S Trout wrote:
> Since people seem to be unsure as to what the alternative to riba's project
> freeze would actually be, let me provide something a little more concrete.

Minor adjustments.

(1) castaway currently holds the SQLT first-come bits and ilmari the SQLA
and DBICSL ones. So I'd propose that if we go with the core team plan then
the DBIC bits get handed to frew.

That way we ended up with an initial core team set up of "the three first
come holders, the project founder, and an arbiter of stability".

(2) As for the arbiter of stability position ... I'm not sure. I wasn't
honestly expecting riba to be quite so closed mouthed there. I stand by the
statement that if whoever riba picked comes forward themselves, I'll happily
add their name to my proposal, but if not, I think you lot are going to have
to figure out a way to pick one yourselves, since the whole point of this
slot is to provide a brake on the rest of us.

(3) This isn't really a third point but I like numbering things: Please
please everybody remember this is a vague draft, you're allowed to propose
adjustments yourselves, oh and if somebody has a plan they think is better
then write it up and propose it - if nothing else, a second plan will
provide for concrete comparisons to refine this one rather than it being
passed through by default.

(4) Same statement as 3, but with an added point: You don't need to have me
back either. Frew's right that I can be kind of an asshole (hell, one of
the reasons I wanted him on this team was because he has a knack for making
me realise I've done it again in time to do something about it), and I've
been mostly gone for a fair few years, and I don't have a concrete vision
here because I was rather expecting riba to do something more sensible than
this so I didn't expect to need one. But I'm happy to try (and there's no
need to reply to fluff my ego if you -are- ok with tolerating me again, I
just don't feel like people whispering 'takeover' later).

-- 
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] A slightly more concrete proposal

[Darren Duncan]

Having just read the C4 spec, I generally find its proposals reasonable.

However, section 2.5 "Branches and Releases" seems too simplistic and I would 
recommend against adopting that part as is.


In particular, its third point:

"To make a stable release a Maintainer shall tag the repository. Stable releases 
SHALL always be released from the repository master."


While that would be fair for smaller projects, it would not work for any 
projects that want to maintain multiple concurrent release branches such as Perl 
itself or Postgres itself do.  This would also apply to projects like DBIC for 
whom the option of stability is paramount.


For that matter, I think the multiple release branch scenario is common and 
important enough that C4 should be updated to explicitly support that as an option.


-- Darren Duncan

On 2016-10-06 10:07 AM, fREW Schmidt wrote:

Woops, didn't mean to refer to the old version of C4.  I don't know
the differences between C4.1 and C4.2 are, but I suspect the newer one
is probably better.  Corrected link is
https://rfc.zeromq.org/spec:42/C4/.

On Thu, Oct 06, 2016 at 09:57:38AM -0700, fREW Schmidt wrote:

Hello friends,

TL;DR:

  * Given that we want stability and community involvment, maybe we
should try C4.1 which optimizes for these.
  * I really strongly think that all members of (AT LEAST) the core
group need to act like adults when conversing with other people,
especially realizing that things that may not be personal attacks
often seem that way when plain text is the mode of discussion.

Exposition below, feel free to skip if you are busy or don't care.

I haven't kept super up to date with these threads, especially since a
lot of it has devolved into email, irc, and blog comment exegesis,
which I don't see as being particularly helpful or valuable.

I wouldn't respond to this again but I am specifically named in
Matt's proposed core team so I felt like it would be warranted.  I
agree that the stability of DBIC is a huge asset.

There are at least two stabilities here: The first is not losing data.
While DBIC has a good track record of this, I personally have
experienced a bug (fixed by ribasushi of course) where the WHERE
clause of a complex delete was lost.  (Yes, the whole table was
deleted.)  This is critical to maintain, and hard.

The more subtle stability, the kind that doesn't get people fired but
instead leaches the time out of our brief lives, is pointless
breakages in backcompat, silly little bugs that have to be worked
around, etc.  This is also hard, and people are less willing to do it,
but if we care about our users (and I do!) we must continue to
maintain it.

There is the hope that DBIC can be maintained by a disparate group.  I
have hope, especially having seen at my current place of employment
that sometimes, throwing conventional wisdom out the window and
deciding to do things a new and better way is a good option.

I am sorta attracted to the model the late Pieter Hintjens came up
with for ∅MQ (C4.1, https://rfc.zeromq.org/spec:22/C4/, except the
specification of [LA]GPL) but am not going to push it hard.  I just
think a model for similarly trusted software might be worth
considering.

I am ok with being part of a core group, although I must caution
everyone: I personally don't have the time nor desires I used to have.
DBIC and it's community have treated me well, and I respect that, but I
can only spill so much blood for Open Source software.

What I am *not* interested in is being a member of a core group where
I have to be the adult in interpersonal conflicts.  Matt, if an idea
is stupid, you can express it constructively.  If it's wrong, say how.
You *must* stop assuming people can or will read your mind or treat
your words as sacred texts to be analyzed character by character.  I
don't expect anyone to be perfect, core group or external, and expect
everyone to make mistakes, but we should at least decide to set a tone
of professionalism, charity, cordiality, or whatever you want to call
it so that we don't end up pointlessly making our small part of the
Perl community more harmful than it needs to be.

--
Station,
Arthur Axel fREW Schmidt
https://blog.afoolishmanifesto.com





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

Re: [Dbix-class] A slightly more concrete proposal

[Darren Duncan]

On 2016-10-06 2:18 AM, Aaron Trevena wrote:


One quick thing to mention, is that SQL and Relational Databases have
moved forward considerably since we were using Class::DBI. I'm now
working on a project using latest Postgres features, and I've been
literally astonished at some of the new stuff that's being made
available by modern relational databases, full JSONB support that's
strong enough for us to replace Mongo, as well as a variety of changes
to SQL such as LATERAL joins mean that the rules are changing under
our feet as developers and that means we can't just stand still either
in how we write database code.

Fortunately we've been able to support these via DBIx::Class using
method modifiers and wrappers and helper classes, as well as the
occasional "big string of literal SQL' but obviously as an entirely
self-interested user (whose most useful contribution is usually acting
as crash test dummy for how idiot proof it is) I believe both
developers and users need to keep up with relational databases or be
left behind.

Thanks again to Peter, Matt and all the contributors - I (and I'm
pretty sure the clients and employers I've had for the last decade)
have appreciated the hard work you've put into this project.


I also agree with what Aaron added here. -- 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] A slightly more concrete proposal

[fREW Schmidt]

Woops, didn't mean to refer to the old version of C4.  I don't know
the differences between C4.1 and C4.2 are, but I suspect the newer one
is probably better.  Corrected link is
https://rfc.zeromq.org/spec:42/C4/.

On Thu, Oct 06, 2016 at 09:57:38AM -0700, fREW Schmidt wrote:
> Hello friends,
> 
> TL;DR:
> 
>  * Given that we want stability and community involvment, maybe we
>should try C4.1 which optimizes for these.
>  * I really strongly think that all members of (AT LEAST) the core
>group need to act like adults when conversing with other people,
>especially realizing that things that may not be personal attacks
>often seem that way when plain text is the mode of discussion.
> 
> Exposition below, feel free to skip if you are busy or don't care.
> 
> I haven't kept super up to date with these threads, especially since a
> lot of it has devolved into email, irc, and blog comment exegesis,
> which I don't see as being particularly helpful or valuable.
> 
> I wouldn't respond to this again but I am specifically named in
> Matt's proposed core team so I felt like it would be warranted.  I
> agree that the stability of DBIC is a huge asset.
> 
> There are at least two stabilities here: The first is not losing data.
> While DBIC has a good track record of this, I personally have
> experienced a bug (fixed by ribasushi of course) where the WHERE
> clause of a complex delete was lost.  (Yes, the whole table was
> deleted.)  This is critical to maintain, and hard.
> 
> The more subtle stability, the kind that doesn't get people fired but
> instead leaches the time out of our brief lives, is pointless
> breakages in backcompat, silly little bugs that have to be worked
> around, etc.  This is also hard, and people are less willing to do it,
> but if we care about our users (and I do!) we must continue to
> maintain it.
> 
> There is the hope that DBIC can be maintained by a disparate group.  I
> have hope, especially having seen at my current place of employment
> that sometimes, throwing conventional wisdom out the window and
> deciding to do things a new and better way is a good option.
> 
> I am sorta attracted to the model the late Pieter Hintjens came up
> with for ∅MQ (C4.1, https://rfc.zeromq.org/spec:22/C4/, except the
> specification of [LA]GPL) but am not going to push it hard.  I just
> think a model for similarly trusted software might be worth
> considering.
> 
> I am ok with being part of a core group, although I must caution
> everyone: I personally don't have the time nor desires I used to have.
> DBIC and it's community have treated me well, and I respect that, but I
> can only spill so much blood for Open Source software.
> 
> What I am *not* interested in is being a member of a core group where
> I have to be the adult in interpersonal conflicts.  Matt, if an idea
> is stupid, you can express it constructively.  If it's wrong, say how.
> You *must* stop assuming people can or will read your mind or treat
> your words as sacred texts to be analyzed character by character.  I
> don't expect anyone to be perfect, core group or external, and expect
> everyone to make mistakes, but we should at least decide to set a tone
> of professionalism, charity, cordiality, or whatever you want to call
> it so that we don't end up pointlessly making our small part of the
> Perl community more harmful than it needs to be.
> 
> -- 
> Station,
> Arthur Axel fREW Schmidt
> https://blog.afoolishmanifesto.com

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

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

Re: [Dbix-class] A slightly more concrete proposal

[fREW Schmidt]

Hello friends,

TL;DR:

 * Given that we want stability and community involvment, maybe we
   should try C4.1 which optimizes for these.
 * I really strongly think that all members of (AT LEAST) the core
   group need to act like adults when conversing with other people,
   especially realizing that things that may not be personal attacks
   often seem that way when plain text is the mode of discussion.

Exposition below, feel free to skip if you are busy or don't care.

I haven't kept super up to date with these threads, especially since a
lot of it has devolved into email, irc, and blog comment exegesis,
which I don't see as being particularly helpful or valuable.

I wouldn't respond to this again but I am specifically named in
Matt's proposed core team so I felt like it would be warranted.  I
agree that the stability of DBIC is a huge asset.

There are at least two stabilities here: The first is not losing data.
While DBIC has a good track record of this, I personally have
experienced a bug (fixed by ribasushi of course) where the WHERE
clause of a complex delete was lost.  (Yes, the whole table was
deleted.)  This is critical to maintain, and hard.

The more subtle stability, the kind that doesn't get people fired but
instead leaches the time out of our brief lives, is pointless
breakages in backcompat, silly little bugs that have to be worked
around, etc.  This is also hard, and people are less willing to do it,
but if we care about our users (and I do!) we must continue to
maintain it.

There is the hope that DBIC can be maintained by a disparate group.  I
have hope, especially having seen at my current place of employment
that sometimes, throwing conventional wisdom out the window and
deciding to do things a new and better way is a good option.

I am sorta attracted to the model the late Pieter Hintjens came up
with for ∅MQ (C4.1, https://rfc.zeromq.org/spec:22/C4/, except the
specification of [LA]GPL) but am not going to push it hard.  I just
think a model for similarly trusted software might be worth
considering.

I am ok with being part of a core group, although I must caution
everyone: I personally don't have the time nor desires I used to have.
DBIC and it's community have treated me well, and I respect that, but I
can only spill so much blood for Open Source software.

What I am *not* interested in is being a member of a core group where
I have to be the adult in interpersonal conflicts.  Matt, if an idea
is stupid, you can express it constructively.  If it's wrong, say how.
You *must* stop assuming people can or will read your mind or treat
your words as sacred texts to be analyzed character by character.  I
don't expect anyone to be perfect, core group or external, and expect
everyone to make mistakes, but we should at least decide to set a tone
of professionalism, charity, cordiality, or whatever you want to call
it so that we don't end up pointlessly making our small part of the
Perl community more harmful than it needs to be.

-- 
Station,
Arthur Axel fREW Schmidt
https://blog.afoolishmanifesto.com

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

Re: [Dbix-class] A slightly more concrete proposal

[Wallace Reis]

This pretty much matches my situation and opinion.

Thanks Riba for the great work so far.

+1 for Matt's plan.

Cheers,

--
Wallace Reis

Em 5 de out de 2016 08:55, "Nigel Metheringham"  escreveu:

Background: I have been a happy DBIx::Class user from the early days.  I
have some code contributions within DBIC and SQLA, although relatively
small ones, but have not had a need to make changes in recent years, so
have recently been a silent DBIC mailing list member.

Riba has put in a lot of work over a number of years maintaining and
improving DBIx::Class - the level of commitment in this should in no way
be understated.

However going forward I would prefer to see an amicable move to a
maintainer team with an initial core membership as indicated by MST.

There needs to remain a focus on ensuring DBIC remains stable and does
not eat data.

Regards

Nigel.

--

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




___
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/
dbix-class@lists.scsys.co.uk
___
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] A slightly more concrete proposal

[Aaron Trevena]

On 4 October 2016 at 21:45, Aaron Crane  wrote:
> Matt S Trout  wrote:
>> Since people seem to be unsure as to what the alternative to riba's project
>> freeze would actually be, let me provide something a little more concrete.
>>
>> This is intended as a basis for discussion rather than a complete plan, but
>> I thought it was worth at least sketching a shape for things to come.
>
> 
>
> I like this proposal a lot. For one thing, having any concrete
> proposal that can be discussed in detail is immensely valuable. As for
> the specific content: this proposal seems to go a very long way to
> ensuring that any concerns about stability can be met appropriately.
>
> In short: +1

Bit late to the party, but I concur.

One quick thing to mention, is that SQL and Relational Databases have
moved forward considerably since we were using Class::DBI. I'm now
working on a project using latest Postgres features, and I've been
literally astonished at some of the new stuff that's being made
available by modern relational databases, full JSONB support that's
strong enough for us to replace Mongo, as well as a variety of changes
to SQL such as LATERAL joins mean that the rules are changing under
our feet as developers and that means we can't just stand still either
in how we write database code.

Fortunately we've been able to support these via DBIx::Class using
method modifiers and wrappers and helper classes, as well as the
occasional "big string of literal SQL' but obviously as an entirely
self-interested user (whose most useful contribution is usually acting
as crash test dummy for how idiot proof it is) I believe both
developers and users need to keep up with relational databases or be
left behind.

Thanks again to Peter, Matt and all the contributors - I (and I'm
pretty sure the clients and employers I've had for the last decade)
have appreciated the hard work you've put into this project.

Cheers,

A.

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

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

Re: [Dbix-class] A slightly more concrete proposal

[Nigel Metheringham]

Background: I have been a happy DBIx::Class user from the early days.  I
have some code contributions within DBIC and SQLA, although relatively
small ones, but have not had a need to make changes in recent years, so
have recently been a silent DBIC mailing list member.

Riba has put in a lot of work over a number of years maintaining and
improving DBIx::Class - the level of commitment in this should in no way
be understated.

However going forward I would prefer to see an amicable move to a
maintainer team with an initial core membership as indicated by MST.

There needs to remain a focus on ensuring DBIC remains stable and does
not eat data.

Regards

Nigel.

-- 

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



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

Re: [Dbix-class] A slightly more concrete proposal

[David Precious]

I haven't waded in on this so far, as I consider others with direct
involvement with the project to have far more weight in their opinions
on that matter, but just for the record:

On Tue, 4 Oct 2016 20:17:08 + Matt S Trout 
wrote:
> 1) I think at this point we should formalise a core team. The BDFL
> model was nice while it lasted, but I don't think it's tenable going
> forwards.
> 
> My first thought for composition would be a five-person team, and
> assuming everybody agrees to it,that being Ilmari, Castaway (Jess
> Robinson), Frew, myself, and whoever riba was planning to pass the
> first-come bits to.
>
> That seems like it should be a nice combination of continuity and
> ensuring that riba's fears we'll be insufficiently conservative being
> given a voice.

I support this.

In particular, I disagree with Riba's idea of removing all existing
co-maints (people who've been given co-maint precisely because they can
be trusted to act in the best interests of the project) and entirely
hand over the reins to an as-yet-unknown person.  Whilst I trust that
Riba would select someone appropriate for the role, I think DBIC is too
important to the Perl ecosystem to be solely controlled by one person.

Matt, you've put a lot of work into the project in the past, along with
a lot of guidance, and your focus on avoiding potential for data loss
is exactly what is needed, so I'd personally certainly want to see you
remain involved in the project as long as you're willing to be.

The others you named as potential core team members are all sensible
choices too, I think.

Also, since I'm posting my opinion, I'd just like to say to Riba,
whatever my opinion of your handover plans, a big thank you for all
your hard work on DBIx::Class - the community owes you gratitude.

Cheers

Dave P (BIGPRESH)


___
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] A slightly more concrete proposal

[James E Keenan]

On 10/04/2016 04:17 PM, Matt S Trout wrote:

Since people seem to be unsure as to what the alternative to riba's project
freeze would actually be, let me provide something a little more concrete.

This is intended as a basis for discussion rather than a complete plan, but
I thought it was worth at least sketching a shape for things to come.

1) I think at this point we should formalise a core team. The BDFL model
was nice while it lasted, but I don't think it's tenable going forwards.

My first thought for composition would be a five-person team, and assuming
everybody agrees to it,that being Ilmari, Castaway (Jess Robinson), Frew,
myself, and whoever riba was planning to pass the first-come bits to.

That seems like it should be a nice combination of continuity and ensuring
that riba's fears we'll be insufficiently conservative being given a voice.



+1 to this in particular, and to the thrust of mst's proposal more 
generally.


From:  A frustrated user of *other* ORMs

___
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] A slightly more concrete proposal

[Darren Duncan]

I agree with this proposal that Matt stated, it seems solid to me.

I will also say that I intend to be a significant DBIC contributor personally 
starting in the near future, estimated about 1 month from now.  Initially that 
will take the form of significant new core features developed in an experimental 
branch, which can then be evaluated by other community members and the core team 
for usefulness.  If accepted these can then be selectively merged into core or 
turned into extensions or inspire work by others as is best practice.  While 
large changes are anticipated as fruit, they are by design intended to be fully 
backwards-compatible with regular user code.


-- Darren Duncan

On 2016-10-04 1:17 PM, Matt S Trout wrote:

Since people seem to be unsure as to what the alternative to riba's project
freeze would actually be, let me provide something a little more concrete.

This is intended as a basis for discussion rather than a complete plan, but
I thought it was worth at least sketching a shape for things to come.

1) I think at this point we should formalise a core team. The BDFL model
was nice while it lasted, but I don't think it's tenable going forwards.

My first thought for composition would be a five-person team, and assuming
everybody agrees to it,that being Ilmari, Castaway (Jess Robinson), Frew,
myself, and whoever riba was planning to pass the first-come bits to.

That seems like it should be a nice combination of continuity and ensuring
that riba's fears we'll be insufficiently conservative being given a voice.

Exactly what would require a formal vote I leave as an open question for the
moment since it boils down to "what would leave both us and the userbase
comfortable things were being properly managed" and that'd require discussion.

2) I certainly wouldn't expect to be merging any clever branches any time
soon - understanding the work that riba did in private without discussion is
going to take time, since while his motivations were good the effect on us
is similar to the effect of taking over from a developer being territorial
in the name of job security - so keeping to careful bugfixes only for at
least the first six months is likely to be the only sensible approach.

3) New feature development will need to be approached carefully, and I
think we'll need to ensure we have a proper code review procedure in place
before merging things into master. Of course, public branches plus lots
of dev releases will also help, as will approaching this as an additive
process where as far as possible the existing logic remains untouched
until we're confident we understand what's going on where.

4) I still remember the fear induced adrenaline surge a little over a decade
ago when I realised that because I wasn't doing regular releases yet, people
were deploying svn trunk against their production database. That's how we got
a regular release cycle and a commitment to backcompat - I have, if anything,
always been more scared of data loss than the average of the user base, to
the point where I got threats from users to fork because we were being too
slow and conservative about adding features. I still believe in that, and
I think so do castaway/frew/ilmari.

5) I continue to believe that things that can be done outside of core should
be done outside of core, and that if at all possible we should prototype
APIs and feature sets in extensions first even if they'd be better served
being in core, but equally, if you look at the limitations of and the insane
code required in http://p3rl.org/DBIx::Class::ParamaterizedJoinHack you can
see that there are still things that core does not yet make as elegant and
robust as one might prefer, and I think it's worth at least trying to
improve on that.

Hopefully that gives people a clearer idea of what I think would end up
happening if we decide to move forwards once again as a team project.




___
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

[Dbix-class] A slightly more concrete proposal

[Matt S Trout]

Since people seem to be unsure as to what the alternative to riba's project
freeze would actually be, let me provide something a little more concrete.

This is intended as a basis for discussion rather than a complete plan, but
I thought it was worth at least sketching a shape for things to come.

1) I think at this point we should formalise a core team. The BDFL model
was nice while it lasted, but I don't think it's tenable going forwards.

My first thought for composition would be a five-person team, and assuming
everybody agrees to it,that being Ilmari, Castaway (Jess Robinson), Frew,
myself, and whoever riba was planning to pass the first-come bits to.

That seems like it should be a nice combination of continuity and ensuring
that riba's fears we'll be insufficiently conservative being given a voice.

Exactly what would require a formal vote I leave as an open question for the
moment since it boils down to "what would leave both us and the userbase
comfortable things were being properly managed" and that'd require discussion.

2) I certainly wouldn't expect to be merging any clever branches any time
soon - understanding the work that riba did in private without discussion is
going to take time, since while his motivations were good the effect on us
is similar to the effect of taking over from a developer being territorial
in the name of job security - so keeping to careful bugfixes only for at
least the first six months is likely to be the only sensible approach.

3) New feature development will need to be approached carefully, and I
think we'll need to ensure we have a proper code review procedure in place
before merging things into master. Of course, public branches plus lots
of dev releases will also help, as will approaching this as an additive
process where as far as possible the existing logic remains untouched
until we're confident we understand what's going on where.

4) I still remember the fear induced adrenaline surge a little over a decade
ago when I realised that because I wasn't doing regular releases yet, people
were deploying svn trunk against their production database. That's how we got
a regular release cycle and a commitment to backcompat - I have, if anything,
always been more scared of data loss than the average of the user base, to
the point where I got threats from users to fork because we were being too
slow and conservative about adding features. I still believe in that, and
I think so do castaway/frew/ilmari.

5) I continue to believe that things that can be done outside of core should
be done outside of core, and that if at all possible we should prototype
APIs and feature sets in extensions first even if they'd be better served
being in core, but equally, if you look at the limitations of and the insane
code required in http://p3rl.org/DBIx::Class::ParamaterizedJoinHack you can
see that there are still things that core does not yet make as elegant and
robust as one might prefer, and I think it's worth at least trying to
improve on that.

Hopefully that gives people a clearer idea of what I think would end up
happening if we decide to move forwards once again as a team project.

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