Code review required for commits - formal Team vote.

[Jeremy Allison]

On Sat, Oct 13, 2012 at 02:23:29AM +0200, Kai Blin wrote:
> On 2012-10-13 01:13, Michael Adam wrote:
> 
> > comments:
> > * I don't yet understand the reasons for "-1"s
> 
> My reason for a -1, as I've tried to explain on both my mail and on IRC
> is that I'd like to try this out first, just like we did for autobuild.
> Jeremy however proposes a policy change now, and says if we don't like
> it later, we can try to get another policy change done. That's not what
> trying things out should look like.
> Apparently that makes me opposed to progress, but I can live with that.

Well I think we differ on semantics :-). My proposal is a request
for people to begin the trial. I don't want to try anything new
without at least a majority of the Team agreeing we should try
it, which is what I'm asking people to vote +1 on - to try this
out.

Once we've agreed to try it out, we do that, and if people find
that patches are getting dropped/not getting addressed in a
timely fashion, then hopefully someone will propose a change
(revert to what we had etc. etc) and we'll vote again to get
consensus on what we need to do about it.

The reason I'm big on voting on this is I don't think such
a change will work without a majority decision to proceed.

If it were just trying out a new tool such as autobuild, then
yeah, we can all do that without needing to formally agree,
but if you remember we eventually did formally agree on using
it. There are no tools to test out here, it's an agreement
to change the way we're doing things.

The reason I want to make that change is that we've been
raising the bar on our software engineering processes
over the lifetime of Samba - remember we started without
even a source code control system :-).

It's been a long time since I worked at a place where
code could be checked in without a formal review process
(I think it was back in the 1990's - the EARLY 1990's :-)
and in order to produce professional software, we really
need to adopt professional standards of development.

Jeremy.