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
|  
Report Content as Inappropriate

Re: GOVERNANCE: Aggregation and conclusion

Wallace Reis-3
On November 2, 2016 at 7:02:46 AM, Dave Cross ([hidden email]) wrote:
> > Mee too.
>
> +1 Matt's proposal (new project team)
> -1 Andrew's proposal (forking)

+1 (new project team)
-1 (forking)

--
Wallace Reis

_______________________________________________
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
|  
Report Content as Inappropriate

Re: GOVERNANCE: Aggregation and conclusion

Darren Duncan
In reply to this post by Peter Rabbitson-2
On 2016-11-02 3:53 AM, Peter Rabbitson wrote:
> 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.

Peter, I don't know your plan, but I think it would be very important if your
own proposal included authorizing a team itself, where you name several
individuals that you trust, and they have PAUSE/etc rights from the start.

The idea here is that even for people who trust you as a benevolent dictator
with control of PAUSE/etc rights, there is still the problem of bus number
equals 1 if your proposal had you being the only one with those rights.
Supporters of your proposal would still want to know that if something happens
to you, others are in the position to govern.

You had already named some people you were more likely to trust would share your
values, and the mysterious successor, so surely there are names for this.

Thank you.

-- 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
|  
Report Content as Inappropriate

Re: GOVERNANCE: Aggregation and conclusion

Darin McBride
In reply to this post by Andrew Beverley
On Monday October 31 2016 11:22:07 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.

There is one piece missing, IMO.  The rest of CPAN.  Maybe there's a simple
solution, maybe this is a non-issue.  But, not knowing the internals of DBIC
plugins, I'm going to ask the dumb questions.


As a user of DBIC, let's say I want to go with the "dangerous" DBIC2 instead
of the stable DBIC.  It has some feature I really want that just got released
next year some time.  However, I have a bunch of DBIx::Class plugins as well.  
Do the plugins Just Work (TM) with DBIC2 despite the namespace change?  
Obviously, my own code needs to derive off a new set of base classes, which I
sort of asked for by virtue of switching.  Ideally, that'd be it - but is it?

If other DBIC modules that exist on CPAN need updating to work with DBIC2
(presumably, they could work against both DBIC and DBIC2), what updating is
it?  What can DBIC2 do to minimise this?

Presumably, some plugins out there are "stable" already and their authors may
have already abandoned them, more or less, is this split going to be a make-
work project, with much angst and gnashing of teeth just to get all the
plugins various DBIC2 users are using updated on CPAN?

If changes need to be made, is there something reasonable that an end-user who
switches can do to monkey-patch things so that DBIC plugins will work with
DBIC2?

Is DBIC2 going to be able to co-exist with DBIC?  Not merely on CPAN, but also
on a user's perl installation?  I'm presuming this would be the plan, but I do
want to ask.

I think this information would greatly impact my ability to vote.  Basically,
how broken is someone if they go with the very first DBIC2 release?  If it will
take 2 or 3 years from the first DBIC2 release until the ecosystem supports it
well enough to make it viable for end-users to switch, I would think the split
would then be basically DOA - it would be entirely moot.  On the other hand,
if there is a list of 5 or fewer steps that users would need to do to start
work with it, including all plugins (e.g., "in your code, switch this use
statement to that, and call this monkey-patch function against your plugins"),
it would tighten the feedback loop to at least make it viable.  Further, if
there is a nice cargo-cult-style chunk of code that plugins can use to auto-
select between DBIC and DBIC2 support, right from that first release, it would
greatly aid in the transition speed.  If, however, no plugin can support both
DBIC and DBIC2 simultaneously without duplicating code or other code smells,
then we would want to really think carefully about advocating a split.  I just
don't know.


I think a secondary set of questions are also in need of asking, though final
decisions on these likely can be deferred to consensus should the split be
approved.  Questions such as whether fixes found in DBIC2 that also affect DBIC
would be offered, whether as patches or pull requests or whatever format riba
would want them in, back to DBIC as a matter of default policy (this does not
tie riba's hands to actually accept them).  And, if riba doesn't accept them
as is but fixes the same problem in another way, would that be merged back to
DBIC2?  Another question here would be whether DBIC updates in general would
be merged into DBIC2.  Having default positions on these from the "split"
side, should it exist, would show priorities as well as indicate whether votes
need to be taken, i.e., if the reverse from the default were being proposed.


_______________________________________________
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
|  
Report Content as Inappropriate

Re: GOVERNANCE: Aggregation and conclusion

Matt S Trout-2
On Wed, Nov 02, 2016 at 04:32:31PM -0600, Darin McBride wrote:

> On Monday October 31 2016 11:22:07 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.
>
> There is one piece missing, IMO.  The rest of CPAN.  Maybe there's a simple
> solution, maybe this is a non-issue.  But, not knowing the internals of DBIC
> plugins, I'm going to ask the dumb questions.
>
>
> As a user of DBIC, let's say I want to go with the "dangerous" DBIC2 instead
> of the stable DBIC.  It has some feature I really want that just got released
> next year some time.  However, I have a bunch of DBIx::Class plugins as well.  
> Do the plugins Just Work (TM) with DBIC2 despite the namespace change?  
> Obviously, my own code needs to derive off a new set of base classes, which I
> sort of asked for by virtue of switching.  Ideally, that'd be it - but is it?

Actually, I think it can potentially be done without needing to force people
to s{}{} their superclass lines, but only given active co-operation between
the people developing both.

Any other approach will, I think, inevitably result in the same sort of
troubles the Dancer/Dancer2 split caused (I argued for managing to maintain
sufficiently backwards compatibility in the new codebase to not require the
split; I lost).

Given I think it's fairly clear at this point that "active co-operation" is
unlikely to describe the relationship between riba and I going forwards, I
hope this explains why I don't consider myself suitable to be involved in
a fork.

--
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
|  
Report Content as Inappropriate

Re: GOVERNANCE: Aggregation and conclusion

Darin McBride
On Wednesday November 2 2016 11:38:35 PM Matt S Trout wrote:

> On Wed, Nov 02, 2016 at 04:32:31PM -0600, Darin McBride wrote:
> > On Monday October 31 2016 11:22:07 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.
> >
> > There is one piece missing, IMO.  The rest of CPAN.  Maybe there's a
> > simple
> > solution, maybe this is a non-issue.  But, not knowing the internals of
> > DBIC plugins, I'm going to ask the dumb questions.
> >
> >
> > As a user of DBIC, let's say I want to go with the "dangerous" DBIC2
> > instead of the stable DBIC.  It has some feature I really want that just
> > got released next year some time.  However, I have a bunch of DBIx::Class
> > plugins as well. Do the plugins Just Work (TM) with DBIC2 despite the
> > namespace change? Obviously, my own code needs to derive off a new set of
> > base classes, which I sort of asked for by virtue of switching.  Ideally,
> > that'd be it - but is it?
> Actually, I think it can potentially be done without needing to force people
> to s{}{} their superclass lines, but only given active co-operation between
> the people developing both.

Yes, we see JSON, JSON::XS, JSON::PP all with a single JSON interface, and
magic happening under the covers. However, because, in theory, all of these
will provide *exactly the same functionality* and interfaces, only a
performance difference, that's fine.  Since the goal of DBIC / DBIC2 is to
diverge, I don't think I'd want to see them "automatically" work for the end
user.  There should, IMO, be some level of action required by the end user to
say "I want DBIC2."  Otherwise there is literally no reason for forking.  Even
if it were "use DBI::Class 2;" (which, obviously, would require active co-
operation, but doesn't really gain us anything over "use DBI::Class2;")

I'm more thinking of the Mo/Moo/Mouse/Moose compatibility, where, with the
right incantations in plugins/other modules, they can work with any of the
above, and the application developer at the end can choose which one to use.  
At least some plugins can, obviously plugins that require the heavier feature
set of Moose won't work with Moo, and that's okay.

Anyway, my question is more pointed at how broken, or not, the rest of the
DBIx::Class namespace would be in a DBIC2 application, especially one that was
working with DBIC and wants to convert to DBIC2.  If much carnage is expected,
then that would affect the voting, I imagine.  Or maybe I'm alone on this.

(I think it is obvious that many applications won't convert, and that's fine, I
would hope and expect no breakage there through any "conversion" process
here.)

> Any other approach will, I think, inevitably result in the same sort of
> troubles the Dancer/Dancer2 split caused (I argued for managing to maintain
> sufficiently backwards compatibility in the new codebase to not require the
> split; I lost).
>
> Given I think it's fairly clear at this point that "active co-operation" is
> unlikely to describe the relationship between riba and I going forwards, I
> hope this explains why I don't consider myself suitable to be involved in
> a fork.


_______________________________________________
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
|  
Report Content as Inappropriate

Re: GOVERNANCE: Aggregation and conclusion

Matt S Trout-2
On Wed, Nov 02, 2016 at 06:08:39PM -0600, Darin McBride wrote:
> Yes, we see JSON, JSON::XS, JSON::PP all with a single JSON interface, and
> magic happening under the covers. However, because, in theory, all of these
> will provide *exactly the same functionality* and interfaces, only a
> performance difference, that's fine.  Since the goal of DBIC / DBIC2 is to
> diverge,

Or the goal could be to have a compatible superset of DBIC's APIs, or it
could be to do something CDICompat style, or ...

If you want to know what the goals would be, first you need to find somebody
who's planning such a fork and ask them, surely.

Otherwise, this conversation seems to basically just be a cheese shop sketch.

--
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
|  
Report Content as Inappropriate

Re: GOVERNANCE: Aggregation and conclusion

Alexander Hartmaier
In reply to this post by Stefan Hornburg (Racke)
I find it funny that people are discussing forking. If there are so many that want a fork why hasn't someone already done it?
It seems most forget that DBIC is open source software. The license doesn't hinder anyone from forking.
The license [1] says on the first two lines:
DBIx::Class is Copyright (c) 2005-2016 by mst, castaway, ribasushi, and others.
See AUTHORS and LICENSE included with this distribution. All rights reserved.
Are all authors also 'Copyright Holders'? If yes how does this affect the current situation?
Imho DBIC isn't 'owned' by anybody, not even after contributing for years like ribasushi did.

Until someone comues up with another proposal I'm +1 for msts.

Best regards, Alex

[1] https://metacpan.org/source/RIBASUSHI/DBIx-Class-0.082840/LICENSE


*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
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
|  
Report Content as Inappropriate

Re: GOVERNANCE: Aggregation and conclusion

Darren Duncan
All authors ARE copyright holders, unless they expressly disclaim or transfer
said rights, which isn't usually the case with CPAN modules.

Due to all of the copyright holders licensing their contributions under an open
source license, anyone is legally empowered to create a fork.

It is important to realize that the current governance issue under discussion is
actually more akin to trademark rights than copying rights, in a sense; it is
about who has the canonical privilege for the NAME "DBIx::Class" within the
context of PAUSE/CPAN.

-- Darren Duncan

On 2016-11-07 1:07 AM, Hartmaier Alexander wrote:

> I find it funny that people are discussing forking. If there are so many that
> want a fork why hasn't someone already done it?
> It seems most forget that DBIC is open source software. The license doesn't
> hinder anyone from forking.
> The license [1] says on the first two lines:
>
> |DBIx::Class is Copyright (c) 2005-2016 by mst, castaway, ribasushi, and others. |||See AUTHORS and LICENSE included with this distribution. All rights reserved.| |
>
> Are all authors also 'Copyright Holders'? If yes how does this affect the
> current situation?
> Imho DBIC isn't 'owned' by anybody, not even after contributing for years like
> ribasushi did.
>
> Until someone comues up with another proposal I'm +1 for msts.
>
> Best regards, Alex
>
> [1] https://metacpan.org/source/RIBASUSHI/DBIx-Class-0.082840/LICENSE


_______________________________________________
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
|  
Report Content as Inappropriate

Re: GOVERNANCE: Aggregation and conclusion

Peter Rabbitson-2
In reply to this post by Peter Rabbitson-2
On 11/02/2016 11:53 AM, Peter Rabbitson wrote:
> I will publish a to-the-point workable proposal by the end
> of this week.
>

Apologies for the delay yet again. Recent emails made articulating my
point more difficult, so I am still thinking on how to properly respond.
There are too many misconception (like e.g. that a fork is avoidable),
and a manner of addressing them all still evades me.

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
|  
Report Content as Inappropriate

Re: GOVERNANCE: Aggregation and conclusion

Matt S Trout-2
On Mon, Nov 07, 2016 at 12:23:36PM +0100, Peter Rabbitson wrote:
> On 11/02/2016 11:53 AM, Peter Rabbitson wrote:
> >I will publish a to-the-point workable proposal by the end
> >of this week.
> >
>
> Apologies for the delay yet again. Recent emails made articulating
> my point more difficult, so I am still thinking on how to properly
> respond. There are too many misconception (like e.g. that a fork is
> avoidable), and a manner of addressing them all still evades me.

Yeah, that's why I asked for monday, let me spend the weekend thinking.

Plus it was easier for me since I already had most of a proposal and
just needed to edit it.

Meanwhile, given I responded to your 'citation needed' request, it'd be
much appreciated if you could respond to my p5p question in the mean time;
I did my best to ask the question in an unprejudicial fashion, and I think
your answer should also help to further highlight where we differ.

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