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

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

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

Alexander Hartmaier
In reply to this post by Jess Robinson
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 <[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@...



*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
Notice: This e-mail contains information that is confidential and may be privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*

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

Re: A slightly more concrete proposal

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

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

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

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

Re: A slightly more concrete proposal

Darren Duncan
In reply to this post by Aaron Trevena
On 2016-10-06 2:18 AM, Aaron Trevena wrote:
<snip>

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

Re: A slightly more concrete proposal

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

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

John SJ Anderson
In reply to this post by Peter Rabbitson-2
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 <[hidden email]> 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@...
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 Peter Rabbitson-2
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@...
Reply | Threaded
Open this post in threaded view
|

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

Peter Rabbitson-2
On 10/07/2016 03:08 AM, Matt S Trout wrote:

> On Mon, Oct 03, 2016 at 11:32:18PM +0200, Peter Rabbitson wrote:
>> Given the discussion generated way more interest than I anticipated, at
>> this point I am pausing all activity ( both code and administrative
>> changes ), until at least the 8th of October. I want to give ample time
>> for all interested parties to state their thoughts.
>
> To replace my earlier reply.
>
> I said it seemed strange to me to cease development when it's obvious that
> both the co-maints and the users would love to have your final work.
>
> However, the emotional toll of this conversation has made it very hard for
> me to write useful code in the meantime.
>
> As such, please everybody take riba's waiting code-wise as being the same
> focus issue, rather than an attempt to punish the user base for disagreeing
> with him, and please also accept my apologies for even implying it might
> have been anything else.
>

Matt,

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

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

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

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

Please stop re-focusing the conversation.


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

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

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

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

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

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

_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@...
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 David Golden
On 10/03/2016 10:37 PM, David Golden wrote:
>
> For those who don't know me, I'm DAGOLDEN on CPAN and I've joined this
> list in my capacity as a PAUSE <http://pause.perl.org> administrator.


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

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

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

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



=== On what is there / what was planned

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

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

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

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

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

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



=== On what is and will happen

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

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

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

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

* As I have neither a functional nor a backup plan, I am requesting
active arbitration from the PAUSE admins. That is - please collect
whatever additional information is necessary, make a decision on the
future leadership of this project, and take an administrative action to
carry this decision out. As indicated in the first part of this email I
pledge to make available all my knowledge and offer my full cooperation
to steady the ship over the coming weeks but I do not think it would be
right for me to try to be the captain that steers us out of this mess.
My only request is to not be placed in a position where I have to make
the FIRSTCOME transfer myself, essentially endorsing the currently
proposed leadership group: my integrity as an engineer simply will not
allow me to click the necessary buttons.

* As a final point on "going forward": I am concerned that the "software
stability" argument has been grossly micharacterized: it was presented
as a binary "does it lose data" argument, when for me the main question
has always been "is it opinionated / does it insist on usurping the
end-users time". To aid in understanding this here are some examples:
    - Frozen project: https://metacpan.org/changes/distribution/Class-DBI
    - Stable project: https://metacpan.org/changes/distribution/DBI
    - Highly unstable (volatile) project:
https://metacpan.org/changes/distribution/Mojolicious


While I will be the first to say the situation is not ideal - this is
what we have. I trust the PAUSE admins will make the best of it.


Regards
RIBASUSHI


[1] http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/012264.html
[2] http://blogs.perl.org/users/peter_rabbitson/2015/12/riba2016-ends.html
[3] https://travis-ci.org/dbsrgits/dbix-class/builds
[4]
http://dbix-class.35028.n2.nabble.com/Re-Traffic-pattern-changes-ahead-td7578918.html
[5] https://github.com/dbsrgits/dbix-class/commit/1cf609901
[6] https://chat.mibbit.com/?channel=%23askriba&server=irc.perl.org
[7] http://www.nntp.perl.org/group/perl.modules/2016/10/msg96182.html
[8]
https://gist.github.com/ribasushi/74ce356123ede727e90f#file-2015-02-20-md

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

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

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

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

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

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

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

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


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

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

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

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

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

Regards,
David

--
David Golden <[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

Matt S Trout-2
In reply to this post by Matt S Trout-2
On Tue, Oct 04, 2016 at 08:17:08PM +0000, 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@...
Reply | Threaded
Open this post in threaded view
|

Re: A slightly more concrete proposal

David Golden
On Sat, Oct 8, 2016 at 10:07 AM, Matt S Trout <[hidden email]> 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 <[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

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

Re: A slightly more concrete proposal

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

Re: 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@...
123456