Code review required for commits - Discuss.

[Andrew Bartlett]

On Fri, 2012-10-12 at 10:25 -0700, Jeremy Allison wrote:
> On Fri, Oct 12, 2012 at 11:31:38AM +0200, Kai Blin wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > On 2012-10-12 10:20, Volker Lendecke wrote:
> > 
> > > Just be a PITA for the reviewers. Send mails, call them, start to
> > > use other means like hop on a train to Goettingen with a LART tool
> > > :-)
> > 
> > That's a reasonable effort for people who work on Samba on their
> > dayjob. I've got to take at least one day off at work to get to
> > Göttingen. On the worst case scenario, that limits me to 30 patchsets
> > a year, assuming I spend all my vacation getting patches in. ;)
> > 
> > I'm still worried that this system is going to leak patches,
> > especially if we don't allow for pushes after patches were ignored for
> > a while.
> > 
> > I think if we go towards a required review system, we really, really
> > need to make sure we don't drop patches.
> 
> Yes. This is a requirement.
> 
> But not a blocker for implementation. If patches are getting
> dropped then patch authors will complain.
> 
> We can revisit this and change policy if things don't seem
> to be working. It's not set in stone.

I'm not willing to commit to a process that makes it harder for larger
or smaller contributors on a 'we can revisit it' basis.  We do not
revisit things well on the Samba Team, and a smaller contributor is much
more likely to say 'stuff it' than to re-open this monster thread. 

The biggest issue here is significant parts of Samba are major
multi-person projects with significant needs for co-ordination, while
other parts of the project are either almost unmaintained or have a
single major contributor. 

Therefore, a one size fits all approach here is entirely unsuitable, and
I'm frustrated that in spite of significant concerns you continue to
push this, rather than work with the concerned parties to figure out
what would:

 - Fix an identified, measured issue
 - Improve our code quality
 - NOT compromise the work of developers who so far disagree with you

If after trying the lightest touch change that can be agreed to meet
those parameters, we fail to address the issue *then* we can revisit it.
We do not need to ramp this from 0 to 10 in one hit, across all of
Samba. 

Were this a collection of projects, we could choose strategies that
would work for each part to benefit of all.  But having spent the past
year and longer working to integrate Samba well enough to produce the
Samba 4.0 we are all justifiably proud of, I'm incredibly opposed to
letting this cleave the project in two again. 

Andrew Bartlett
-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org