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
|

GOVERNANCE: Aggregation and conclusion

Matt S Trout-2
(this message bcc'ed to [hidden email] for the record, not cc'ed in the
hopes of minimising the odds of unintended cross-list reply carnage)

So, everything seems to've settled down. I've just gone back through and
attempted to extract votes out of the various threads, possibly imperfectly,
and in the case of my proposal considering people who said "yes, but" to be
simply against it in the name of fairness.

Here's the summary:

Governance+core team proposal:

Tue Oct 18:

http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/012331.html

Updated Wed Oct 19 by:

http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/012365.html

In favour:

http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/012336.html
http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/012339.html
http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/012340.html
http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/012342.html
http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/012343.html
http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/012345.html
http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/012348.html
http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/012350.html
http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/012355.html
http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/012359.html
http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/012360.html
http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/012362.html
http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/012366.html

Against:

http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/012332.html
http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/012357.html
http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/012358.html
http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/012360.html

13 for, 4 against, for a total of +9.

DBIC/DBIC2 proposal:

Sun Oct 23:

http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/012370.html

In favour:

http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/012371.html
http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/012374.html
http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/012378.html
http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/012379.html
http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/012389.html
http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/012390.html

Against:

http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/012383.html
http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/012388.html

6 for, 2 against, for a total of +4.

Combine these numbers with the fact that the objections to the governance
proposal were primarily of the form of "this needs to be tweaked" and the
boostrap phase update I made gives us time to do so, whereas the objections
to the alternative were outright, I believe the overall will of the
community is at this point relatively clear.

For those of you who think a two stream release system is a good idea in
general ... it's entirely possible it could be, and I think a discussion
of that later would be a good idea, but I expect that for the first few
months we'll primarily be getting settled and handling bugfixes and figuring
out what potential future features we even want, and I'd rather not second
guess plans that aren't made as yet. So, basically, "let's definitely come
back to that, but let's wait until we have a concrete basis from which to
discuss it before doing so". Plus even an untweaked version of the governance
document means (intentionally) I can't stop you forcing a vote on it at any
point you want to.

As such, I hereby call upon the PAUSE administration to adjust the permissions
for all namespaces within the DBIx::Class distribution in accordance with:

http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/012365.html

Once this is done, I intend to commit the GOVERNANCE document to master and
we can enter the bootstrap phase to thrash the governance system into a shape
people are actively happy with.

Peter, if you have any remaining code to push, shout and I'll be happy to
defer committing the governance document for a few days since it's pretty
uncontested that you know what you're doing and I can't see how that can't
be a net positive.

Ladies, gentlemen, and mongers, thank you for bearing with us through this
process and I look forward to working together going forwards.

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

David Golden
On Sat, Oct 29, 2016 at 3:17 PM, Matt S Trout <[hidden email]> wrote:
As such, I hereby call upon the PAUSE administration to adjust the permissions
for all namespaces within the DBIx::Class distribution in accordance with:

http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/012365.html

I'm very pleased to see how the DBIC community has engaged in honest discussion about self-governance.  It's been a long road, but one that I think will serve the community well going forward.

I'll make the changes in the next 24-48 hours and make a final announcement when it's done.

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

Andrew Beverley
On Sat, 29 Oct 2016 20:47:20 -0400 David Golden <[hidden email]> wrote:
> I'm very pleased to see how the DBIC community has engaged in honest
> discussion about self-governance.  It's been a long road, but one
> that I think will serve the community well going forward.
>
> I'll make the changes in the next 24-48 hours and make a final
> announcement when it's done.

Given that there was no formal vote, I think this is a somewhat hasty
and unfair conclusion. It's a bit like having an election with only one
party, having people vote, and then mentioning a second party later
once the election's finished. I personally was just about to vote in
favour of the "governance+core team" proposal, when I went through all
the emails and came to the second conclusion.

Personally I would like to see a straightforward "A vs B" vote. Only
then will I consider this a fair decision.

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

Charlie Garrison
On 30 Oct 2016, at 19:43, Andrew Beverley wrote:

> Personally I would like to see a straightforward "A vs B" vote. Only
> then will I consider this a fair decision.

+1

--

   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

Dmitry Bigunyak
In reply to this post by Andrew Beverley
>Given that there was no formal vote, I think this is a somewhat hasty
>and unfair conclusion. It's a bit like having an election with only one
>party, having people vote, and then mentioning a second party later
>once the election's finished. I personally was just about to vote in
>favour of the "governance+core team" proposal, when I went through all
>the emails and came to the second conclusion.
>
>Personally I would like to see a straightforward "A vs B" vote. Only
>then will I consider this a fair decision.
>
>Andy

Heh, I'm actually totally agree with that.
I was silently following the discussion and never had the feeling that all this time there was a voting process going on...
Matt, David, sorry guys, but it all feels like you just using the community to do what we've already decided to do.

--
Dmitry
e-mail: [hidden email]
_______________________________________________
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

Matt S Trout-2
In reply to this post by Andrew Beverley
(bcced again to the modules list)

On Sun, Oct 30, 2016 at 08:43:03AM +0000, Andrew Beverley wrote:
> Given that there was no formal vote, I think this is a somewhat hasty
> and unfair conclusion. It's a bit like having an election with only one
> party, having people vote, and then mentioning a second party later
> once the election's finished. I personally was just about to vote in
> favour of the "governance+core team" proposal, when I went through all
> the emails and came to the second conclusion.
>
> Personally I would like to see a straightforward "A vs B" vote. Only
> then will I consider this a fair decision.

Excellent.

This entire argument exists because riba wanted to plan his succession (a
plan that he has always refused to explain) without even bothering to talk
to the user base.

I, personally, preferred to actually let the userbase decide what happened,
hence the (apparently insufficient) attempt at voting that riba grudgingly
agreed to.

I am entirely in favour of a multi-proposal vote, and will be happy to abide
by the result of the list aggregate vote.

If anybody wishes to make a third proposal, they probably should do so now.

Otherwise, I would suggest that you turn your plan into a full proposal, and
I have time to update my governance proposal, and then we allow Q&A about
both, and then we vote.

As such, I petition the PAUSE administration to leave things alone while the
community sorts things out, given it's clear that everybody except ribasushi
would prefer things to be decided by democracy than fiat.

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

David Golden
On Sun, Oct 30, 2016 at 8:43 PM, Matt S Trout <[hidden email]> wrote:
As such, I petition the PAUSE administration to leave things alone while the
community sorts things out


Sure.  We've always maintained that there was no rush and that discussion was the best course of action.

I encourage those presenting alternate proposals to focus on governance, not merely project direction, as I think it will benefit the community to have a mechanism for determining direction, permissions, etc. not just now but going forward.

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

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

Re: GOVERNANCE: Aggregation and conclusion

James E Keenan
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.

Thank you very much.
Jim Keenan

_______________________________________________
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 7:22 AM, Andrew Beverley <[hidden email]> wrote:
- RIBASUSHI retains the current namespace


Peter previously said that he would only continue if all other maintainers relinquished their claims to the DBIC namespace [1].  Could you please clarify your proposal with details on that front and what is to happen should Peter be unable or unwilling to continue working on DBIC?

If Peter agrees and your proposal carries, I don't want to be in a situation where we have to have this debate again if he decides to take his "well deserved retirement" after all (regardless of whether immediately after the permissions change or some unknown time in the future).

Speaking personally, what I like about Matt's governance proposal is that it explicitly establishes a continuity plan.  I think any alternative proposal ought to be equally clear about continuity and succession.

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

Dagfinn Ilmari Mannsåker
In reply to this post by James E Keenan
James E Keenan <[hidden email]> writes:

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

-1 from me too.  I think forking will harm both sides, as the
already-limited contributor pool gets fragmented across two code bases.


- ilmari

--
"The surreality of the universe tends towards a maximum" -- Skud's Law
"Never formulate a law or axiom that you're not prepared to live with
 the consequences of."                              -- Skud's Meta-Law


_______________________________________________
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

Patrick Meidl-2
On Mon, Oct 31 2016, Dagfinn Ilmari Mannsåker <[hidden email]> wrote:

> James E Keenan <[hidden email]> writes:
>
> > 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.
>
> -1 from me too.  I think forking will harm both sides, as the
> already-limited contributor pool gets fragmented across two code bases.

-1 for the same reason.

    patrick

--
Patrick Meidl, Mag.
Senior Expert Software Engineering

IST - Institute of Science and Technology Austria
Am Campus 1
A-3400 Klosterneuburg, Austria

R I21.EG.115 (Building West, BT01)
T +43 2243 9000 1313
E [hidden email]
W https://icp.ist.ac.at/search/users/pmeidl



_______________________________________________
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 Andrew Beverley
+1 on this proposal.

everyone should be happy with this. From reading silently all the proposals in this thread, it is clear that we all want DBIC to move forward, if that means letting RIBA have the namespace and MST and the new governance to be able to work on DBIC freely, then separating the namespaces is the most sensible and pragmatic thing to do IMO. 

If RIBA does not have time or willingness to keep working on DBIC or contributing code, then the old namespace dies, as many other Perl modules and namespaces do. It's called evolution.

The worst that can happen is active development in both namespaces, and then having the problem of parallel (convergent, duplication of , efforts; or divergent) in any case, paradoxically that would be a good thing! 

But being a biologist by training, just let me say that we shouldn't care too much about how the project will evolve. You cannot direct or guide evolution, you just see it happen. 

Let's not be dramatic about this, it happened to all the BSDs in the past. FreeBSD, NetBSD, OpenBSD, ... forks for focusing a critical mass of developers on different aspects (security, portability, etc). They still share and exchange code and ideas, or even big architectural changes when something developed by one project makes sense for all others. 

Let's fork, let go of namespaces, and move on!

--
fernan

On Mon, Oct 31, 2016 at 8:22 AM, Andrew Beverley <[hidden email]> 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



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

Leo Lapworth
In reply to this post by Andrew Beverley
On 31 October 2016 at 11:22, Andrew Beverley <[hidden email]> 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

If we are having a A vs B vote, someone needs to put together a proposal
that has been fully researched and working out governance processes
for the project(s) as a whole...

- If we are forking, is there ANY pretence of trying to maintain
interoperability
between the 2 namespaces, if there is how does that get governed?

- Can anyone other than Ribasushi have any say in DBIx::Class changes,
as I've just seen David comment, what happens when he does want to
retire again?

- I'm not sure the people previously mentioned would be interested
in working on a fork (DBIx::Class2), they might be, but someone would need
to discuss this with them and then come back to the list with a confirmation
of that.

These are only initial thoughts, there is much more detail that someone
would need to work through....

We shouldn't start voting until there is a FULL researched and formal proposal,
rather than some general ideas about a possible direction.

Maybe someone could formally step forward to co-ordinate putting
together this alternative proposal?

Leo

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

Re: GOVERNANCE: Aggregation and conclusion

Chase Whitener
In reply to this post by Dagfinn Ilmari Mannsåker
-1 from me, too.

On Mon, Oct 31, 2016 at 8:42 AM, Dagfinn Ilmari Mannsåker
<[hidden email]> wrote:

> James E Keenan <[hidden email]> writes:
>
>> 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.
>
> -1 from me too.  I think forking will harm both sides, as the
> already-limited contributor pool gets fragmented across two code bases.
>
>
> - ilmari
>
> --
> "The surreality of the universe tends towards a maximum" -- Skud's Law
> "Never formulate a law or axiom that you're not prepared to live with
>  the consequences of."                              -- Skud's Meta-Law
>
>
> _______________________________________________
> List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
> IRC: irc.perl.org#dbix-class
> SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
> Searchable Archive: http://www.grokbase.com/group/dbix-class@...

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

Re: GOVERNANCE: Aggregation and conclusion

Christian Walde
In reply to this post by Andrew Beverley
On Mon, 31 Oct 2016 12:22:07 +0100, Andrew Beverley <[hidden email]>  
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,
>
> But, in that case, I propose:

I think mst was referring to your plan of having an "A v B" vote.

--
With regards,
Christian Walde

_______________________________________________
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 David Golden
On 10/31/2016 01:39 PM, David Golden wrote:

> On Mon, Oct 31, 2016 at 7:22 AM, Andrew Beverley <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     - RIBASUSHI retains the current namespace
>
>
> Peter previously said that he would only continue if all other
> maintainers relinquished their claims to the DBIC namespace [1].  Could
> you please clarify your proposal with details on that front and what is
> to happen should Peter be unable or unwilling to continue working on DBIC?
>
> If Peter agrees and your proposal carries, I don't want to be in a
> situation where we have to have this debate again if he decides to take
> his "well deserved retirement" after all (regardless of whether
> immediately after the permissions change or some unknown time in the
> future).

Same here (wrt not wanting to re-live this situation again). I will
respond to the above points around midnight UTC ( ~11h from now ).



_______________________________________________
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
In reply to this post by David Golden
On Mon, 31 Oct 2016 08:39:29 -0400 David Golden <[hidden email]> wrote:
> On Mon, Oct 31, 2016 at 7:22 AM, Andrew Beverley <[hidden email]> wrote:
>
> > - RIBASUSHI retains the current namespace
> >
> >
> Peter previously said that he would only continue if all other
> maintainers relinquished their claims to the DBIC namespace [1].

Yes, that would be the case, as that would prevent this situation
happening again.

> Could you please clarify your proposal with details on that front and
> what is to happen should Peter be unable or unwilling to continue
> working on DBIC?

It would be no different to any other module. Ribasushi nominates
someone should he be able to, otherwise:

http://www.cpan.org/misc/cpan-faq.html#How_adopt_module

Personally I trust Ribasushi to make such a nomination, and I know
others do. If there are more people that don't, then that's what this
vote is for.

> If Peter agrees and your proposal carries, I don't want to be in a
> situation where we have to have this debate again if he decides to
> take his "well deserved retirement" after all

The only reason we're in this situation is because of MST's (perfectly
reasonable) claims to the namespace. This would clarify ownership once
and for all, and leave the decision with the module owner, as it
presumably is with all other modules.

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

David Golden
On Mon, Oct 31, 2016 at 9:42 AM, Andrew Beverley <[hidden email]> wrote:
> Could you please clarify your proposal with details on that front and
> what is to happen should Peter be unable or unwilling to continue
> working on DBIC?

It would be no different to any other module. Ribasushi nominates
someone should he be able to, otherwise:

http://www.cpan.org/misc/cpan-faq.html#How_adopt_module

Personally I trust Ribasushi to make such a nomination, and I know
others do. If there are more people that don't, then that's what this
vote is for.


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).

(Of course, given his change in employment circumstances, he might not do that – he might faithfully continue to maintain DBIC for years to come.)

Speaking as PAUSE administrator, there is no objection to "B" if that's what the community wants.  It would merely be another way for the community to resolve the initial dispute.

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

Andrew Beverley
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).

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