Re: [Dbix-class] PROPOSAL: Governance and sustainability

[Andrew Beverley]

Thanks for the updated governance MST. Just one comment/question from
me (this is not intended to be critical because I made the previous
alternate proposal, it's a genuine concern that I would like to see
answered that led me to make the previous alternative proposal):

> Voting Members are:
> 
>   Matt S Trout (mst) cpan:MSTROUT
>   Dagfinn Ilmari Mansaker (ilmari) cpan:ILMARI
>   Frew Schmidt (frew) cpan:FREW
>   Jess Robinson (castaway) cpan:JROBINSON

I'd like to hear some commitment from the above list that they have the
time and capacity (and to some extent experience) to comprehensively
review relevant changes. My concern is that relatively significant
changes could be proposed (and implemented), and not get the scrutiny
that they should have. If proposals get no votes (or "yeah looks okay
to me" type votes), then that's actually worse than a BDFL-type
approach, as the implementer gets a false sense of security that their
work is being reviewed, when they might otherwise have been more
careful.

I realise that there is the list vote as well, but my comments above
still stand in that regard (especially re experience - I would have no
idea whether proposed changes affect stability).

What I'm really trying to say is that we've all seen situations where
programmers (including me) have been more lax than they should have
been, when they think they have some sort of other security checking
their changes (be it peer-reviews, test suites, whatever).

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@lists.scsys.co.uk

Re: [Dbix-class] Please don't try to start voting yet

[Darren Duncan]

On 2016-11-07 1:38 PM, Matt S Trout wrote:

Since, as Andy Beverley pointed out, a straight A/B vote is the most
effective way to provide a clear resolution, please do add comments and
thoughts to my proposal (and do the same for riba once he's able to figure
out his), but there's no point doing +1/-1 as yet.

Once we've seen and discussed both, *then* we can call the final vote.
Otherwise people are just going to feel railroaded again and that isn't to
anybody's advantage.


Here's an idea.  In the spirit of your proposal, how about when the discussion 
seems to be over and it seems time to vote, either Matt or Peter would propose 
that a vote occurs, with the VOTE email etc, and then the other one of those two 
would second it if they agree, at which point the vote happens. -- 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@lists.scsys.co.uk

Re: [Dbix-class] Please don't try to start voting yet

[Andrew Beverley]

On Mon, 7 Nov 2016 21:38:13 Matt S Trout  wrote:
> Once we've seen and discussed both, *then* we can call the final vote.

Thanks MST, that makes much more sense, much appreciated.

___
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@lists.scsys.co.uk

Re: [Dbix-class] PROPOSAL: Governance and sustainability

[Darren Duncan]

Having read Matt's new proposal and its correction, it comes across as 
reasonable and workable to me.  I have no thoughts at this time as to how it 
could be improved.  This message is just feedback, and does not make any 
relative value judgements between Matt's proposal and Peter's upcoming one. -- 
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@lists.scsys.co.uk

Re: [Dbix-class] GOVERNANCE: Aggregation and conclusion

[Matt S Trout]

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@lists.scsys.co.uk

Re: [Dbix-class] PROPOSAL: Governance and sustainability

[Matt S Trout]

I'm an idiot.

> Voting closes after 72h from when the proposal was first posted.

This line should be replaced with:

  Voting closes after 72h from when the VOTE: email is sent.

My apologies.

-- 
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@lists.scsys.co.uk

[Dbix-class] Please don't try to start voting yet

[Matt S Trout]

Since, as Andy Beverley pointed out, a straight A/B vote is the most
effective way to provide a clear resolution, please do add comments and
thoughts to my proposal (and do the same for riba once he's able to figure
out his), but there's no point doing +1/-1 as yet.

Once we've seen and discussed both, *then* we can call the final vote.
Otherwise people are just going to feel railroaded again and that isn't to
anybody's advantage.

-- 
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@lists.scsys.co.uk

[Dbix-class] PROPOSAL: Governance and sustainability

[Matt S Trout]

The updated bootstrap governance document appears below - basically I've
attempted to tweak it so that, while business as usual can occur without
needing the list to expend time getting involved, the community now gets
a clear veto - and there's a forcible recall method (forced vote) to defend
against the possibility of a rogue core team. I hope that said addition is
never required, but strongly believe there should be some final means of
redress in such a scenario.

Also, I'm encoding frew holding first-come, since I hold SQL::Abstract,
castaway SQL::Translator, and ilmari DBIx::Class::Schema::Loader, so it
seems like a sensible place to leave them.

I also want to give a rough idea of what I'm expecting to actually happen:

- The first days will be pure bugfixing while we get a handle on the codebase
- I don't intend to do a CPAN release at all without an RC release first to
  begin with, because (1) let's be careful (2) that means people can use the
  RC if they desperately need a bugfix sooner than the release vote will be
  completed
- I, personally, currently have no specific significant changes to propose,
  though that doesn't mean other people can't do so
- Once we do have a solid handle on the codebase, I expect any potential
  feature additions to be discussed before we start work, in order to ensure
  that the risk/reward trade-offs have been thoroughly covered
- I intend to prioritise letting people who want a specific feature work on
  it themselves, providing code review and design assistance, over doing so
  myself, so that we end up with a long-term viable team again
- There is absolutely increased short-term risk to doing it that way, but I
  believe that we need both stability and sustainability, since neither a
  broken nor a dead project is desirable in a core dependency
- If you don't think we've been sufficiently careful in that regard, you
  have the ability to veto both merges and releases. I've tried to bake
  "if in doubt, make the conservative choice" into the system itself
  intentionally, and would much rather have a rebellion before than after
  a release is shipped to CPAN.

With all that given, here's the updated governance document:

=begin GOVERNANCE

DBIx::Class Core Team and Voting System

Non normative section:

DBIx::Class originally operated under a BDFL system, but one where it was
expected that an informal core team would be maintained, and that where
consensus could not be pre-assumed, the core team and/or the user base
would be consulted publically such that measured decisions could be made.

This document is intended to formalise a form of this system, while still
providing room for the system to adapt later as required.

It is intended that this system provides confidence to the user base that
decisions will be made in the open and that their wishes will be taken into
account.

It is also intended that this system allows business as usual to happen
without unnecessary red tape.

It is not intended that this system becomes the primary decision making
process in and of itself; instead, it is intended that this system is used
to ratify consensus as formed by discussion, and only sparingly as a tie
breaking system when consensus cannot be reached.

Normative section:

Terms: VM - Voting Member - part of the benevolent dictatorship
   LS - List Subscriber - a subscriber to the mailing list
   LAV - List Aggregate Vote - the aggregate vote of the non-VM LSes

Voting Members are:

  Matt S Trout (mst) cpan:MSTROUT
  Dagfinn Ilmari Mansaker (ilmari) cpan:ILMARI
  Frew Schmidt (frew) cpan:FREW
  Jess Robinson (castaway) cpan:JROBINSON

PAUSE release perms are to be held by:

  Matt S Trout (mst) cpan:MSTROUT
  Dagfinn Ilmari Mansaker (ilmari) cpan:ILMARI
  Frew Schmidt (frew) cpan:FREW
  Jess Robinson (castaway) cpan:JROBINSON

First come permissions are to be held by FREW.

(the above two lists may or may not be identical at any given time)

A resolution must be proposed and then successfully voted upon to:

  - Make a PAUSE-indexed (i.e. non-dev) release of DBIx::Class
  - Make changes to the master and blead branches of the repository
  - Amend this document

This document is currently in bootstrap phase, and as such no merges will be
made to master or blead until this sentence is removed.

A resolution that amends the 'PAUSE release perms' list is to be assumed to
also intend the permission within PAUSE itself to be updated accordingly.

Adding or removing entries from the list of situations requiring resolutions
is absolutely a valid topic for resolutions.

A resolution may be proposed for reasons including, but not limited to:

  - Force/revert/block a branch merge
  - Add/remove a commit bit
  - Resolve a design discussion
  - Anything you like, under the assumption frivolous proposals will be
voted down naturally anyway

Merges to topic branches and similar actions that do not have a resolution
attached may be made at the discretion of those with 

Re: [Dbix-class] The email I didn't want to write.

[Matt S Trout]

On Tue, Nov 08, 2016 at 07:32:02AM +1100, Charlie Garrison wrote:
> On 7 Nov 2016, at 20:24, Hartmaier Alexander wrote:
> 
> >Peter is also 'only' a human being and if his interpersonal skills
> >would
> >be higher his technical expertise might not be as good as it is
> >because
> >no one can shine everywhere.
> 
> It seems to me that people bashing ribasushi should be working on
> their own interpersonal skills. I’ve yet to hear any arguments or
> see any evidence which voids Peter’s technical expertise.

DBIx::Class is dependent on, and a dependency of, many components of
the overall CPAN ecosystem.

I consider riba's increasing unwillingness to apply his technical expertise
constructively to the ecosystem, but instead to make decisions like

  (ribasushi) at this point it is *my engineering duty* to drive him
  away from perl

to be a material risk to the future of the project; many of us have been
working around him for over a year now to avoid conflict on the expectation
that he was going to be retiring anyway, and if he remains and continues
to behave the same way it's going to be very difficult for DBIx::Class to
get the voice it deserves in discussions around related modules.

> When I come against who I believe to be a very stubborn person who
> won’t listen, I take the opportunity to improve my communication and
> reasoning skills (assuming something important, otherwise just walk
> away). Making the ‘the problem’ someone else just makes the
> situation harder for me; it’s much easier to fix myself than fix
> someone else.

That's an attitude that you and I generally share; what I find unfortunate
is deciding to break somebody else instead of convincing them to do the
right thing.

-- 
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@lists.scsys.co.uk

Re: [Dbix-class] The email I didn't want to write.

[Charlie Garrison]

On 7 Nov 2016, at 20:24, Hartmaier Alexander wrote:

Peter is also 'only' a human being and if his interpersonal skills 
would
be higher his technical expertise might not be as good as it is 
because

no one can shine everywhere.


It seems to me that people bashing ribasushi should be working on their 
own interpersonal skills. I’ve yet to hear any arguments or see any 
evidence which voids Peter’s technical expertise.


When I come against who I believe to be a very stubborn person who 
won’t listen, I take the opportunity to improve my communication and 
reasoning skills (assuming something important, otherwise just walk 
away). Making the ‘the problem’ someone else just makes the 
situation harder for me; it’s much easier to fix myself than fix 
someone else.


cng

--

   Charlie Garrison  
   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@lists.scsys.co.uk

Re: [Dbix-class] GOVERNANCE: Aggregation and conclusion

[Peter Rabbitson]

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@lists.scsys.co.uk

Re: [Dbix-class] The email I didn't want to write.

[Hartmaier Alexander]

Can everybody please stop bashing ribasushi and work on a solution to
get the DBIC development process going again?!

Peter is also 'only' a human being and if his interpersonal skills would
be higher his technical expertise might not be as good as it is because
no one can shine everywhere.

Thanks!


On 2016-11-03 18:34, Christian Walde wrote:

On Wed, 02 Nov 2016 11:50:24 +0100, Peter Rabbitson
 wrote:


Citation needed. Please provide an example where I have been abusive
or even slightly unprofessional in a bugreport. Issue trackers are
generally always part of the public record, so it shouldn't be a
problem to back up what was said above.


I didn't want to bother, but rereading riba's arrogance and deceit
combined with your past actions make me angry enough to bother.

He'll probably enjoy that i write this, but well, if he does, he's
free to enjoy it while he can.

Meanwhile i think it's only fair that his userbase knows what his
principles really *mean*.

The following did not have him act in an RT queue, but since his
actions were in direct response and aimed towards affecting a ticket i
filed, it is fair to bring up.

He did abuse me on IRC with the goal to get me to give up on the ticket.

He plainly said this to me and tried to justify it as being his duty
as an engineer.

I did indeed give up on a ticket despite still considering it valid
and in need of action due to him.

I had forgotten about it for months and not done anything about it at
all. A reasonable person should think that would be enough for him to
cross it off as done and leave things be.

However for some insane reason he thought it was appropiate to
approach me again, a YEAR after i had originally filed the ticket, and
tell me these things:

[...]
16-01-08@23:11:43 (ribasushi) I re-read the log in p5p several times
in the past week
[...]
16-01-08@23:12:21 (ribasushi) if you agree for me to publish it
unmodified (at most with slight reorder to compensate for IRC lag)
16-01-08@23:12:33 (ribasushi) I will publicly own to say in no
uncertain terms that I went *EASY* on you
16-01-08@23:12:35 (ribasushi) and that I regret it
16-01-08@23:13:09 (Mithaldu) regret going easy, or having done it in
the first place instead of looking at it on technical merits?
16-01-08@23:13:22 (ribasushi) I looked at the technical merits
16-01-08@23:13:25 (Mithaldu) also, publish whatever you liked
16-01-08@23:13:33 (ribasushi) and I didn't shut it down quickly enough
nor forcefully enough
16-01-08@23:13:39 (Mithaldu) jesus fuck
16-01-08@23:13:43 (ribasushi) I wasn't using "radical candor" correctly
16-01-08@23:13:46 (Mithaldu) you are an abbhorrent piece of shit
16-01-08@23:13:53 (ribasushi) and this is something I do regret
[...]

He might possibly argue that this was him being professional,
delivering a final kick to the liver to ensure it sticks.

However in no possible conceivable way does this deserve ANY respite
from receiving the label "abusive".

I am also not the only person to be treated like that. He said the
following about his treatment of another developer in various venues,
including a github queue:

15-05-11@14:00:22 (ribasushi) at this point it is *my engineering
duty* to drive him away from perl

Again, he probably thinks it is professional to do that, but trying to
claim here that it is not abuse is a lie, given he has stated outright
that he was abusing said dev with that particular goal.





*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
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@lists.scsys.co.uk

Re: [Dbix-class] 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@lists.scsys.co.uk

Re: [Dbix-class] GOVERNANCE: Aggregation and conclusion

[Hartmaier Alexander]

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@lists.scsys.co.uk