[Dbix-class] PROPOSAL: Governance and sustainability

[Matt S Trout]

On Tue, Nov 08, 2016 at 07:06:10AM +0000, Andrew Beverley wrote:
> 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):

There's a reason why the opposition in parliament is called "Her Majesty's
Loyal Opposition" and so far all of your disagreement with and questioning
of my ideas has absolutely seemed to me to be in that spirit (rather more
so than our actual politicians manage, of course).
 
> > 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).

So, I think we all have at least some familiarity with the codebase. We're
not perfect, but basically we're the best available, and pretty much the
best people-not-riba (and given he's re-iterated more than once that he's
going to provide a guide to the codebase, that should rather help). More
importantly, I think we all have the sense to say "looks ok to me, but I'm
not sure", at which point somebody else should take a look and we should
probably make a note to ship a dev release with the patch in and make people
test it *before* it gets merged anywhere (dev releases are cheap :).

I see what you mean about the "was this review thorough" question, though;
I would I think argue that it's expected that whoever makes the PROPOSAL for
a merge should have done a thorough review of the code - or at least have
the assurances of somebody who has.

Since the proposals are going to be recorded, I think that, basically,
your reasons why you believe that merging something is (a) going to do
something useful (b) not going to break anything should be included in the
proposal, so that the reasoning is greppable later if we need it.

Which means that while the list vote can't necessarily tell if we've checked
carefully enough, they can at least tell if the analysis for (b) seems half
arsed and tell us to try harder. And writing up those analyses for the future
record seems a useful thing to do to me *anyway*, and I figure over time
we'll settle on a reasonable set of trade-offs over 'effort required to
merge something' versus 'how well we trust our merges'.

What seems to regularly get lost in this conversation is that, well, my
views on "how much conservatism is enough" are still a long way towards
the conservative end of the spectrum; there've been quite a few #toolchain
arguments over the years that were basically "mst and riba versus everybody
else". But beyond pointing that out, I'm not sure how I prove that we're
going to take this seriously except for to get the chance to take it
seriously and successfully get it right.

I'd be perfectly happy to formalise merge proposals as requiring sections
X, Y and Z to be written out - or we can do it informally for the first few,
with the LAV voting us down if we underdo it, and then commit something into
the governance doc once the system's baked.

Apologies for the slightly waffly response, but I'm trying to tease out the
various aspects, while suffering from the problem, roughly, of "I already
believe in us as, at least, the best people to try, so I'm unsure what
assurances would work" while at the same time wanting a process that actually
works as well as looking comforting.

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