GOVERNANCE: Aggregation and conclusion

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

Re: GOVERNANCE: Aggregation and conclusion

Andrew Beverley
On Mon, 31 Oct 2016 14:18:59 Andrew Beverley <[hidden email]> wrote:

> On Mon, 31 Oct 2016 10:12:27 -0400 David Golden <[hidden email]> wrote:
> > So to be absolutely clear, it sounds like proposal "B" is to grant
> > Peter the unilateral power initially in dispute.
> >
> > I.e. he could – on arbitrary day N after your proposal is adopted –
> > merge his remaining work, transfer permissions to an unknown person
> > with an unknown mandate, and retire (aka. the original "project
> > freeze" plan).
>
> Yes, correct, just like lots of other "upstream" module maintainers
> could do the same.
>
> Like I say, I personally trust him not to cause such a train-smash,
> but if others don't and would rather see him leave the project
> altogether, then the vote is their opportunity to say so (or under my
> proposal they could use DBIx::Class2 of course).

(I should add that this is just my view based on Riba's previous
comments. We should at least let him have his own point of view on the
matter, which he will presumably provide later today).

_______________________________________________
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: GOVERNANCE: Aggregation and conclusion

Michael Hamlin
In reply to this post by Andrew Beverley
I am in favor of Andy's proposal (forking).  My current understanding is there are developers interested in working in both directions, and this proposal permits that to happen.

If the projects diverge, so be it.  If one ceases to be actively maintained, so be it.  This is not unusual in OSS or CPAN.  End users will always have the choice which to use (or continue using), or whether to switch.

I do not think a "succession plan" is necessary for this proposal, because I trust Peter to be responsible and responsive to the users, the fact that abandoned repos can be reassigned, and that any written succession plan is not necessarily going to actually help in an uncertain future.

As I said before, governance and direction do not seem to me entirely independent discussions, and attempts to split them may depress user involvement.  Its like voting for a candidate without knowing their platform.  As an end-user, I care a lot about direction.  My feelings about governance can change as I hear more about what folks are proposing to do.

thanks,
michael

p.s. I didn't appreciate the feeling of "rush to judgment" that this thread began with.  I can understand that to some this discussion feels like its dragging on, but if you want to listen to users, you need to give plenty of time.  (I can't even read this mailing list on a daily basis, much less cogitate and respond!)

_______________________________________________
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: GOVERNANCE: Aggregation and conclusion

Aaron Trevena
In reply to this post by James E Keenan
On 31 October 2016 at 12:18, James E Keenan <[hidden email]> wrote:

> On 10/31/2016 07:22 AM, Andrew Beverley wrote:
>>
>> On Mon, 31 Oct 2016 00:43:31 Matt S Trout <[hidden email]> wrote:
>>>
>>> Otherwise, I would suggest that you turn your plan into a full
>>> proposal,
>>
>>
>> TBH, I didn't even realise I was making a proposal until I saw the
>> results[1]. I was merely bringing up one of Dave's earlier
>> suggestions[2], which several others also seemed to like.
>>
>> But, in that case, I propose:
>>
>> - RIBASUSHI retains the current namespace, continuing to maintain and
>> tighten that code base. The aim would be a rock-solid module with a
>> very conservative rate of change and new features.
>>
>> - A new namespace DBIx::Class2 is created, owned and operated by MST's
>> governance+core team proposal. Developers that want to create new
>> features do so in this namespace.
>>
>> I do not understand the technicalities, but from what I have seen
>> discussed, people would still be able to use DBIx::Class::* modules in
>> both namespaces.
>>
>
> -1 on this proposal from me.  I favor getting on with the existing proposal.

Another -1 on new namespace, existing proposal seems more sustainable.

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: GOVERNANCE: Aggregation and conclusion

fREW Schmidt
In reply to this post by Andrew Beverley
+1

On Mon, Oct 31, 2016 at 11:22:07AM +0000, Andrew Beverley wrote:

> On Mon, 31 Oct 2016 00:43:31 Matt S Trout <[hidden email]> wrote:
> > Otherwise, I would suggest that you turn your plan into a full
> > proposal,
>
> TBH, I didn't even realise I was making a proposal until I saw the
> results[1]. I was merely bringing up one of Dave's earlier
> suggestions[2], which several others also seemed to like.
>
> But, in that case, I propose:
>
> - RIBASUSHI retains the current namespace, continuing to maintain and
> tighten that code base. The aim would be a rock-solid module with a
> very conservative rate of change and new features.
>
> - A new namespace DBIx::Class2 is created, owned and operated by MST's
> governance+core team proposal. Developers that want to create new
> features do so in this namespace.
>
> I do not understand the technicalities, but from what I have seen
> discussed, people would still be able to use DBIx::Class::* modules in
> both namespaces.
>
> The advantages of this proposal are:
>
> 1. Users get a choice. If they are happy with the current feature set
> and need rock-solid performance and stability, then they can use DBIC.
> If they need new features or want to use a module that has a quicker
> development pace, then they can use DBIC2.
>
> 2. Ribasushi continues to contribute to the code base, both in terms of
> potentially migrating proven-solid features from DBIC2 to DBIC, and in
> terms of keeping his expertise engaged.
>
> Andy
>
> [1] http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/012392.html
> [2] http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/012237.html
>
> _______________________________________________
> 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@...

--
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: GOVERNANCE: Aggregation and conclusion

David Golden
In reply to this post by Andrew Beverley
On Mon, Oct 31, 2016 at 10:18 AM, Andrew Beverley <[hidden email]> wrote:
On Mon, 31 Oct 2016 10:12:27 -0400 David Golden <[hidden email]> wrote:
> So to be absolutely clear, it sounds like proposal "B" is to grant
> Peter the unilateral power initially in dispute.
>
> I.e. he could – on arbitrary day N after your proposal is adopted –
> merge his remaining work, transfer permissions to an unknown person
> with an unknown mandate, and retire (aka. the original "project
> freeze" plan).

Yes, correct, just like lots of other "upstream" module maintainers
could do the same.

Like I say, I personally trust him not to cause such a train-smash

Please read the section entitled "=== Future Plans" in this message from Peter: http://www.nntp.perl.org/group/perl.modules/2016/10/msg96174.html

What I suggested was not a hypothetical "train-smash" intended to scare you or others.  It was literally his plan for DBIC as of Oct 1.

In making your proposal "B", you are indicating that you support that specific plan if that's what Peter decides is best for DBIC now or at any point in the future.

Again, I have no objections if the DBIC community gives informed consent to such a plan.  Speaking personally, I can understand the appeal of such certainty around stability.

I, too, look forward to Peter's thoughts, as perhaps his thinking on the matter has evolved since a month ago.

Regards,
David


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

Re: GOVERNANCE: Aggregation and conclusion

Andrew Beverley
On Mon, 31 Oct 2016 11:22:32 -0400 David Golden <[hidden email]> wrote:
> Please read the section entitled "=== Future Plans" in this message
> from Peter:
> http://www.nntp.perl.org/group/perl.modules/2016/10/msg96174.html
>
> What I suggested was not a hypothetical "train-smash" intended to
> scare you or others.  It was literally his plan for DBIC as of Oct 1.

I wouldn't call that a train-smash. In fact, I'd call it the complete
opposite (if such a thing exists, maybe a power cut to the whole rail
network).

I agree it was a poor proposal, and certainly not something I wanted to
see happen, but it was what he believed was best at the time to ensure
continued stability (arguable, but I'm referring to intent).

That's no longer his plan though, a new proposal is on the table, and
a re-evaluation of the options is required by the user base.

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: GOVERNANCE: Aggregation and conclusion

Darren Duncan
In reply to this post by Peter Rabbitson-2
My current thought is that a fork may be the best solution in the short term,
with the following clarifications or amendments.

1. Peter Rabbitson would have the exclusive PAUSE permissions to the DBIx::Class
namespace and would continue to perform releases of his work on it as he wanted
to do.  He would also designate others to have those permissions as he chooses,
and he would choose his own successor.  This namespace would emphasize stability
and/or Peter's objectives.

2. Matt would create a fork using his proposed governance model to further
evolve along those lines.  The fork would emphasize their objectives, and would
probably include most major work not done by Peter.

3. I hope that Peter would still be open to pull requests but he should publish
some documentation giving an outline of what qualities he would look for in
patches from others so they would more likely be accepted.  My assumption
however, is that in a fork scenario most pull requests would just go to the
fork, and pull requests on the original would be limited to small things like
security or bug fixes.

4. In the future, if Peter decides to leave again and/or there is no successor,
the DBIx::Class namespace can be treated according to abandoned module protocol,
where Peter has no outstanding interest, unlike now.

5. Ideally DBIC, both versions, would be as duck-typed as possible with its API,
so that dependent modules or applications could switch between them more easily,
without having to do a lot of tests on the names of classes.

This all being said, I am ALSO fine with Matt's governance proposal being used
with the DBIx::Class namespace, though given that Peter's further committer
involvement is basically mutually exclusive with this, I consider it less ideal
for that reason.

I also recognize that DBIC has its own network of extensions, and I don't know
if they are duck-typed or not, eg would they themselves need substantial or any
changes to work in a forked ecosystem, or if one could use them with both
different-names DBIC versions unchanged.

I see that as a main complicating factor.  Applications, not so much; if they
want stability, Peter's version should serve them; if they want substantial
changes or new features that more likely may be in the fork, they would have to
be changed anyway.

-- 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: GOVERNANCE: Aggregation and conclusion

Dmitry Bigunyak
In reply to this post by Andrew Beverley
>On Mon, 31 Oct 2016 00:43:31 Matt S Trout < [hidden email] > wrote:
>> Otherwise, I would suggest that you turn your plan into a full
>> proposal,
>
>TBH, I didn't even realise I was making a proposal until I saw the
>results[1]. I was merely bringing up one of Dave's earlier
>suggestions[2], which several others also seemed to like.
>
>But, in that case, I propose:
>
>- RIBASUSHI retains the current namespace, continuing to maintain and
>tighten that code base. The aim would be a rock-solid module with a
>very conservative rate of change and new features.
>
>- A new namespace DBIx::Class2 is created, owned and operated by MST's
>governance+core team proposal. Developers that want to create new
>features do so in this namespace.
>
>I do not understand the technicalities, but from what I have seen
>discussed, people would still be able to use DBIx::Class::* modules in
>both namespaces.
>
>The advantages of this proposal are:
>
>1. Users get a choice. If they are happy with the current feature set
>and need rock-solid performance and stability, then they can use DBIC.
>If they need new features or want to use a module that has a quicker
>development pace, then they can use DBIC2.
>
>2. Ribasushi continues to contribute to the code base, both in terms of
>potentially migrating proven-solid features from DBIC2 to DBIC, and in
>terms of keeping his expertise engaged.
>
>Andy
>

+1 to the "fork proposal" as the solution which should satisfy most of the people.
I don't really share concerns regarding the team fragmentation, instead having a choice and maybe even healthy competition is definitely a good thing.

--
Dmitry Bigunyak
_______________________________________________
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: GOVERNANCE: Aggregation and conclusion

Fernan Aguero-3-3
In reply to this post by Darren Duncan
+1 for the fork 

On Mon, Oct 31, 2016 at 6:24 PM, Darren Duncan <[hidden email]> wrote:
My current thought is that a fork may be the best solution in the short term, with the following clarifications or amendments.

1. Peter Rabbitson would have the exclusive PAUSE permissions to the DBIx::Class namespace and would continue to perform releases of his work on it as he wanted to do.  He would also designate others to have those permissions as he chooses, and he would choose his own successor.  This namespace would emphasize stability and/or Peter's objectives.

2. Matt would create a fork using his proposed governance model to further evolve along those lines.  The fork would emphasize their objectives, and would probably include most major work not done by Peter.

3. I hope that Peter would still be open to pull requests but he should publish some documentation giving an outline of what qualities he would look for in patches from others so they would more likely be accepted.  My assumption however, is that in a fork scenario most pull requests would just go to the fork, and pull requests on the original would be limited to small things like security or bug fixes.

4. In the future, if Peter decides to leave again and/or there is no successor, the DBIx::Class namespace can be treated according to abandoned module protocol, where Peter has no outstanding interest, unlike now.

5. Ideally DBIC, both versions, would be as duck-typed as possible with its API, so that dependent modules or applications could switch between them more easily, without having to do a lot of tests on the names of classes.

This all being said, I am ALSO fine with Matt's governance proposal being used with the DBIx::Class namespace, though given that Peter's further committer involvement is basically mutually exclusive with this, I consider it less ideal for that reason.

I also recognize that DBIC has its own network of extensions, and I don't know if they are duck-typed or not, eg would they themselves need substantial or any changes to work in a forked ecosystem, or if one could use them with both different-names DBIC versions unchanged.

I see that as a main complicating factor.  Applications, not so much; if they want stability, Peter's version should serve them; if they want substantial changes or new features that more likely may be in the fork, they would have to be changed anyway.

-- Darren Duncan



--
fernan

_______________________________________________
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: GOVERNANCE: Aggregation and conclusion

Thomas Klausner
In reply to this post by James E Keenan
Hi!

On Mon, Oct 31, 2016 at 08:18:13AM -0400, James E Keenan wrote:

> On 10/31/2016 07:22 AM, Andrew Beverley wrote:
> > On Mon, 31 Oct 2016 00:43:31 Matt S Trout <[hidden email]> wrote:
> > > Otherwise, I would suggest that you turn your plan into a full
> > > proposal,
> >
> > TBH, I didn't even realise I was making a proposal until I saw the
> > results[1]. I was merely bringing up one of Dave's earlier
> > suggestions[2], which several others also seemed to like.
> >
> > But, in that case, I propose:
> >
> > - RIBASUSHI retains the current namespace, continuing to maintain and
> > tighten that code base. The aim would be a rock-solid module with a
> > very conservative rate of change and new features.
> >
> > - A new namespace DBIx::Class2 is created, owned and operated by MST's
> > governance+core team proposal. Developers that want to create new
> > features do so in this namespace.

-1

I think a fork will not work. The "old" DBIC will stagnate, the "new"
will not gain traction. Everybody loses.

Greetings,
domm


--
#!/usr/bin/perl                              http://domm.plix.at
for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}

_______________________________________________
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: GOVERNANCE: Aggregation and conclusion

Ashley Pond V
+1 for the fork. It's the only way to eat our cake and have it;
affording different lines of development and culture without friction
and strife.

Since very few, if any, of you were here at the beginning, you
probably don't know that this is essentially how DBIx::Class was born;
as an indirect fork from Class::DBI. It was the right thing then. It's
the right thing now. I adore and am grateful for MST's experiments and
use them whenever I can. On the other side, I was the one who
introduced DBIC at Fortune company #5, so stability and speed have
become the most important concerns to me and my group.

_______________________________________________
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: GOVERNANCE: Aggregation and conclusion

Renvoize, Martin

Totally agree with Ashley there, could not have said it better myself

"Ashley Pond V" wrote:
>
> +1 for the fork. It's the only way to eat our cake and have it;
> affording different lines of development and culture without friction
> and strife.


_______________________________________________
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: GOVERNANCE: Aggregation and conclusion

Charlie Garrison
In reply to this post by Thomas Klausner
On 1 Nov 2016, at 19:48, Thomas Klausner wrote:

> I think a fork will not work. The "old" DBIC will stagnate, the "new"
> will not gain traction. Everybody loses.

Agreed. Another,

-1

Charlie

--

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

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

Re: GOVERNANCE: Aggregation and conclusion

Matthias Zeichmann
On Tue, Nov 1, 2016 at 10:45 PM, Charlie Garrison <[hidden email]> wrote:
On 1 Nov 2016, at 19:48, Thomas Klausner wrote:

> I think a fork will not work. The "old" DBIC will stagnate, the "new"
> will not gain traction. Everybody loses.

Agreed. Another,

same here

-1 for forking, +1 for the original proposal
--
siggen.pl: Segmentation Fault

_______________________________________________
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: GOVERNANCE: Aggregation and conclusion

Dave Cross-2

Quoting Matthias Zeichmann <[hidden email]>:

> On Tue, Nov 1, 2016 at 10:45 PM, Charlie Garrison <[hidden email]>
> wrote:
>
>> On 1 Nov 2016, at 19:48, Thomas Klausner wrote:
>>
>> > I think a fork will not work. The "old" DBIC will stagnate, the "new"
>> > will not gain traction. Everybody loses.
>>
>> Agreed. Another,
>>
>
> same here
>
> -1 for forking, +1 for the original proposal

Mee too.

+1 Matt's proposal (new project team)
-1 Andrew's proposal (forking)

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: GOVERNANCE: Aggregation and conclusion

Paul Mooney
On 02.11.2016 09:02, Dave Cross wrote:

> Quoting Matthias Zeichmann <[hidden email]>:
>
>> On Tue, Nov 1, 2016 at 10:45 PM, Charlie Garrison
>> <[hidden email]>
>> wrote:
>>
>>> On 1 Nov 2016, at 19:48, Thomas Klausner wrote:
>>>
>>> > I think a fork will not work. The "old" DBIC will stagnate, the "new"
>>> > will not gain traction. Everybody loses.
>>>
>>> Agreed. Another,
>>>
>>
>> same here
>>
>> -1 for forking, +1 for the original proposal
>
> Mee too.
>
> +1 Matt's proposal (new project team)
> -1 Andrew's proposal (forking)

Same here:

+1 Matt's proposal
-1 to forking


_______________________________________________
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: GOVERNANCE: Aggregation and conclusion

Stefan Hornburg (Racke)
On 11/02/2016 10:07 AM, Paul Mooney wrote:

> On 02.11.2016 09:02, Dave Cross wrote:
>> Quoting Matthias Zeichmann <[hidden email]>:
>>
>>> On Tue, Nov 1, 2016 at 10:45 PM, Charlie Garrison <[hidden email]>
>>> wrote:
>>>
>>>> On 1 Nov 2016, at 19:48, Thomas Klausner wrote:
>>>>
>>>> > I think a fork will not work. The "old" DBIC will stagnate, the "new"
>>>> > will not gain traction. Everybody loses.
>>>>
>>>> Agreed. Another,
>>>>
>>>
>>> same here
>>>
>>> -1 for forking, +1 for the original proposal
>>
>> Mee too.
>>
>> +1 Matt's proposal (new project team)
>> -1 Andrew's proposal (forking)
>
> Same here:
>
> +1 Matt's proposal
> -1 to forking
>

+1 Matt's proposal
+1 to forking

I think we should at least give interested developers a chance to play
with DBIx::Class and test out new features.

It can just live on Github and not on CPAN until something useful
emerges out of it. In case that doesn't happen, the repo can
be closed.

Regards
          Racke

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


--
Ecommerce and Linux consulting + Perl and web application programming.
Debian and Sympa administration.


_______________________________________________
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: GOVERNANCE: Aggregation and conclusion

Peter Rabbitson-2
In reply to this post by Peter Rabbitson-2
On 10/31/2016 02:40 PM, Peter Rabbitson wrote:
>
> Same here (wrt not wanting to re-live this situation again). I will
> respond to the above points around midnight UTC ( ~11h from now ).
>

Apologies for my silence. The combination of a time-zone shift with an
unusually early day-start leaves me way less "productive time" than I
anticipated. I will publish a to-the-point workable proposal by the end
of this week.

Stay tuned.

_______________________________________________
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: GOVERNANCE: Aggregation and conclusion

David Precious
In reply to this post by Stefan Hornburg (Racke)

From me, it's a +1 to Matt's proposal (new project team) and -1 to
forking - I don't want to see the current DBIx::Class languishing, and
I think it's something far more valuable to be managed by a team.

As much as I respect riba for all the work he's put in, his recent
behaviour concerns me greatly, and doesn't leave me filled with
confidence of him being sole gatekeeper of the DBIx::Class namespace
and everything that relies upon it - and even if I still had full faith
in him being the man for the job, the bus factor is too low for
something so important.

Whilst, yes, people could change to "use DBIx::Class2" or whatever a new
fork was called if they want the new stuff, that's a lot of
already-out-there code relying on something with a single maintainer,
and a lot of CPAN dists which depend on DBIx::Class which would need to
decide which version to target, etc.



On Wed, 2 Nov 2016 10:11:25 +0100
"Stefan Hornburg (Racke)" <[hidden email]> wrote:
> I think we should at least give interested developers a chance to play
> with DBIx::Class and test out new features.
>
> It can just live on Github and not on CPAN until something useful
> emerges out of it. In case that doesn't happen, the repo can
> be closed.

Being on GitHub, people can arbitrarily fork with one click to their own
repository, play with it as they wish, and if they end up with
something they think is good and useful, offer to contribute it back.

Isn't that what GitHub is /for/? :)


_______________________________________________
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: GOVERNANCE: Aggregation and conclusion

Stefan Hornburg (Racke)
In reply to this post by Stefan Hornburg (Racke)
On 11/02/2016 10:11 AM, Stefan Hornburg (Racke) wrote:

> On 11/02/2016 10:07 AM, Paul Mooney wrote:
>> On 02.11.2016 09:02, Dave Cross wrote:
>>> Quoting Matthias Zeichmann <[hidden email]>:
>>>
>>>> On Tue, Nov 1, 2016 at 10:45 PM, Charlie Garrison <[hidden email]>
>>>> wrote:
>>>>
>>>>> On 1 Nov 2016, at 19:48, Thomas Klausner wrote:
>>>>>
>>>>>> I think a fork will not work. The "old" DBIC will stagnate, the "new"
>>>>>> will not gain traction. Everybody loses.
>>>>>
>>>>> Agreed. Another,
>>>>>
>>>>
>>>> same here
>>>>
>>>> -1 for forking, +1 for the original proposal
>>>
>>> Mee too.
>>>
>>> +1 Matt's proposal (new project team)
>>> -1 Andrew's proposal (forking)
>>
>> Same here:
>>
>> +1 Matt's proposal
>> -1 to forking
>>
>
> +1 Matt's proposal
> +1 to forking
>

Sorry, the choices were confused by me - so my corrected vote is

+1 Matt's proposal (new project team)
-1 to forking

Regards
          Racke


--
Ecommerce and Linux consulting + Perl and web application programming.
Debian and Sympa administration.


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