IMPORTANT: A discussion of DBIC governance and future development

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

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

Louis Erickson

Hello, all.

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

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

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

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

(more below...)

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

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


Is this really needed?

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

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

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

Please don't lock DBIC down.


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

Re: A slightly more concrete proposal

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

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

Matt S Trout-2
In reply to this post by Matt S Trout-2
Meanwhile:

Riba presents

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

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

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

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

Subject: Re: Message from PAUSE Admins to DBIx::Class maintainers [resend]
To: Matt S Trout <[hidden email]>, Graham Knop <[hidden email]>,
 David Golden <[hidden email]>, "[hidden email]" <[hidden email]>

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

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

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


--
Matt S Trout - Shadowcat Systems - Perl consulting with a commit bit and a clue

http://shadowcat.co.uk/blog/matt-s-trout/   http://twitter.com/shadowcat_mst/

Email me now on mst (at) shadowcat.co.uk and let's chat about how our CPAN
commercial support, training and consultancy packages could help your team.

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

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

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

> Meanwhile:
>
> Riba presents
>
> https://web.archive.org/web/20161004214347/http://blogs.perl.org/users/peter_rabbitson/2013/07/crowdsourcing-self-confidence.html#comment-1129854
>
> as a to-him unamnbiguous legitimisation of his first come, except that in
> there my entire goal was to turn DBIx::Class into a team project again, which
> if you read my comment will, I hope, be obvious.
>
> As I said then: "I suspect what we need to try and achieve is to get DBIC a
> bit more decentralised" - and I stand by that now, hence my proposal of a
> core team.

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

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

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

-- Darren Duncan


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

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

Karen Etheridge
In reply to this post by David Golden
On Sun, Oct 2, 2016 at 4:31 AM, Peter Rabbitson <[hidden email]> wrote:
> I again must stress that there has been a huge 9+ months "discussion
> period" during which nobody (besides mst) came forward expressing
> concerns regarding my plans.

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

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

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

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

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

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

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

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


- Karen Etheridge, [hidden email]


On Mon, Oct 3, 2016 at 1:37 PM, David Golden <[hidden email]> wrote:
Hello, DBIC community.

I apologize in advance for the length of this email, but I urge everyone that uses DBIC to read it fully as it relates to the future of this important module.

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

For those on the list who aren't familiar with CPAN administration, PAUSE is the service that authors use to upload modules to CPAN.  Among other functions, it generates the index that maps modules names to downloadable tarballs – e.g. "DBIx::Class" to "RIBASUSHI/DBIx-Class-0.082840.tar.gz" on a CPAN mirror.

PAUSE also maintains a permissions model [2] for each module namespace with two levels: "primary maintainer" (also called "first come") and "co-maintainer" (aka "co-maint").  Primary maintainers can grant and revoke co-maint permissions.  Both levels can upload tarballs to PAUSE, triggering an update to the index.

Over the past several weeks, I've been the PAUSE administrator selected to mediate a dispute over future disposition of primary permissions for the DBIx::Class namespace.

The dispute was triggered by Peter Rabbitson's "Traffic pattern changes ahead" [3] email to this list on September 6, in which he said:

I have also firmly selected who will be getting the DBIx::Class
namespace first-come[2], the transfer of which will also happen
somewhere around the end of September.

Because the identity of the new primary maintainer was neither disclosed nor discussed with Matt Trout (the founder of the DBIC project, current co-maintainer and also PAUSE administrator) or other co-maintainers, several private conversations between ensued between Matt, Peter and others about this declaration.

On September 15, Peter notified PAUSE administrators via the [hidden email] mailing list of an "Upcoming PAUSE permissions dispute" [4].  Separately, Matt notified PAUSE administrators privately with his own concerns about a possible dispute (his email was later disclosed and I'll link to it later).

On September 21, I privately emailed all DBIC maintainers (CPAN authors ABRAXXA, ARODLAND, FREW, ILMARI, JROBINSON, MSTROUT, and RIBASUSHI) on behalf of PAUSE administrators with our collective view of how this dispute would be best resolved.  Peter asked that any discussion be public, so I reposted it to the [hidden email] mailing list as "Message from PAUSE Admins to DBIx::Class maintainers [resend]" [5]

I urge everyone to read that thread in full as well.  For reference, it includes a copy [6] of Matt's previously private email to PAUSE administrators.

Importantly, the thread summarizes PAUSE administrators' position on the dispute, which I repost verbatim here:

(1) Given the importance of DBIC to the broader Perl community (i.e. way
"upriver" <http://neilb.org/2015/04/20/river-of-cpan.html>), we’d like to
see a more open discussion between existing maintainers about what happens
next in terms of DBIC leadership and control of primary permissions.

(2) The best outcome from our perspective would be for a successor to be
decided by consensus of existing maintainers.

(3) Given a dispute among maintainers, the only outcome that is absolutely
unacceptable to PAUSE admins would be a unilateral permissions transfer
decision.

(4) We really hope the DBIC maintainers and/or community can resolve this
internally.

In the ensuing discussion, Peter disclosed additional details about his plans for the future of DBIC in the "Future plans" section of this email [7]:

I am still planning to wrap up the remaining pieces, including some
unannounced initiatives to get the project into the best shape possible
to survive its leaderlessness.

I am still planning to remove all co-maint perms and handover the
first-come to a yet-undisclosed person. Given no clear line of
succession, and the incredibly high stakes wrt compatibility, the only
responsible thing to do is to select a single spot of responsibility and
provide all possible support and infrastructure for a proper
project-freeze.

In another email [8], Peter suggested raising these issues explicitly on the DBIC mailing list:

As suggested in an earlier email: the PAUSE admins (as the only
legitimate concerned party at this point) would likely benefit having
this question asked in a wider forum ( the DBIC mailing list and/or
other channels ). Essentially someone has to trigger a "vote of no
confidence", otherwise this entire exchange is just a time consuming farce.

On behalf of the PAUSE administrators, we would therefore like to invite Peter to describe in more detail his plans for a "project freeze" and the role he envisions for a successor maintainer.  We invite Matt, other co-maintainers, and the DBIC community at large to add their thoughts about the specifics of the plan or about the situation in general.

Given public and private discussions to date, we believe the DBIC community should consider questions such as:

  • How should the future governance of the DBIC project be decided?
  • Who should or shouldn't be involved in future governance?
  • Should the project be "frozen" or should development continue?
  • If "frozen", what specifically would a "freeze" entail? Would there be exceptions?
  • If not "frozen", what principles should govern development?  (Cathedral vs Bazaar [9] and/or New Jersey Style vs MIT Style [10])
We believe these discussions, if had openly, honestly and constructively, will lead to the best resolution of this dispute for the DBIC community.

Thank you for reading this far, and I look forward to reading the community's views on these matters.

Sincerely,
David Golden, PAUSE Administrator

_______________________________________________
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

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

On 10/05/2016 05:24 AM, Karen Etheridge wrote:
>
> 3) Since I had contracted Peter (via my employer) for particular patches
> last
> year, I didn't want to say or do anything that would distract him or disrupt
> that work, or become a conflict of interest with it; see also (2).

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

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

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


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

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

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

Why?

On Tue, Oct 4, 2016 at 11:37 PM, Peter Rabbitson <[hidden email]> wrote:
This is not a response to the entirety of your email, but just one particular bit.

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

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

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

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

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


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

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

David Golden
In reply to this post by Christian Walde
On Tue, Oct 4, 2016 at 4:35 PM, Christian Walde <[hidden email]> wrote:
[Peter] preparing [his] feature-frozen-bugfix-only release in a different
namespace; mst's plan being used in the DBIx::Class namespace.

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

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

Some of the benefits I could see from this:

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

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

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

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

Sincerely,
David

--
David Golden <[hidden email]> 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@...
Reply | Threaded
Open this post in threaded view
|

Re: A slightly more concrete proposal

David Precious
In reply to this post by Matt S Trout-2

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 +0000 Matt S Trout <[hidden email]>
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@...
Reply | Threaded
Open this post in threaded view
|

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

Colin Newell
In reply to this post by David Golden
On 5 October 2016 at 09:07, David Golden <[hidden email]> wrote:
> * DBIx::Class2 (DBIC2) – new feature development, with lower stability
> expectations
>

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

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

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


Colin.

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

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

Peter Rabbitson-2
In reply to this post by Karen Etheridge
On 10/05/2016 08:50 AM, Karen Etheridge wrote:
>> It is now much harder to advance either of these points.
>
> Why?
>

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

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

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

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


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

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

Leo Lapworth
Hi,

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

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

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

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

Leo

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

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

Colin Newell
On 5 October 2016 at 11:23, Leo Lapworth <[hidden email]> wrote:

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

Ditto.

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

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

Lasse Makholm
In reply to this post by Leo Lapworth
On Wed, Oct 5, 2016 at 12:23 PM, Leo Lapworth <[hidden email]> wrote:

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

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

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

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

/Lasse

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

_______________________________________________
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

Louis Erickson

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

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

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

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


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

Re: A slightly more concrete proposal

Dave Cross-2
In reply to this post by David Precious

Quoting David Precious <[hidden email]>:

> 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 +0000 Matt S Trout <[hidden email]>
> 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.

This nicely sums up my thoughts on Matt's proposal too.

+1

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

Darin McBride
In reply to this post by Peter Rabbitson-2
On Wednesday October 5 2016 11:44:47 AM Peter Rabbitson wrote:

> On 10/05/2016 08:50 AM, Karen Etheridge wrote:
> >> It is now much harder to advance either of these points.
> >
> > Why?
>
> Because now that you causally dropped an insinuation that a part of the
> work I put into DBIC itself was performed for material gain, a casual
> reader could interpret this entire thread as "Ribasushi tried to
> strangle a CPAN project for his own profit". That would be despite the
> fact that the core of your ( very complex and multi-layered )
> work-related issue is in a module outside of ( and discouraged by ) the
> DBIC project, and as such entirely outside of the scope of this discussion.

Do you not need to put food on the table, the same as the rest of us? Do you
not need to put a roof over your head, clothes on your body?

If only I could get paid to play on computers, with code, to do my hobby in
exchange for cash.

Oh, that's right, I do.  It's my job.  A lot of material gain there.

Why shouldn't you get paid for your efforts when and where you can?  Why is
that somehow sullying your effort?  If your DBIC contributions are still of the
high quality you've been providing with all the focus on compatibility, why
does it matter who is paying for it?  Because the bottom line is that someone
*is* paying for it.  Why does it always have to be you who is paying?  And how
does that hurt anyone else?

Finish the job, take the money.  No one, and I mean NO one, will think less of
you for it.  On the contrary, many of us will (and do) envy your ability to
extend this volunteer activity into contract work for money.

We don't think less of a volunteer for prioritising their day job over their
volunteer contributions, nor for prioritising your contract work.  We all have
to eat.

_______________________________________________
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

Jess Robinson
In reply to this post by Peter Mottram
On Tue, 04 Oct 2016 19:20:51 +0100, Peter Mottram <[hidden email]> 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@...
Reply | Threaded
Open this post in threaded view
|

Re: A slightly more concrete proposal

Aaron Trevena
In reply to this post by Aaron Crane
On 4 October 2016 at 21:45, Aaron Crane <[hidden email]> wrote:

> Matt S Trout <[hidden email]> 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.
>
> <snip>
>
> 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@...
Reply | Threaded
Open this post in threaded view
|

Re: A slightly more concrete proposal

Wallace Reis-3
In reply to this post by David Precious

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" <[hidden email]> 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 ------------------------------ [hidden email] ]
[                 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@...
123456