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