third_party and how we make big/controversial changes in samba
abartlet at samba.org
Sun Aug 10 16:33:03 MDT 2014
On Fri, 2014-08-08 at 13:04 -0700, Jeremy Allison wrote:
> On Sat, Aug 09, 2014 at 07:50:20AM +1200, Andrew Bartlett wrote:
> > Please also remember to get metze's explicit ACK on this.
> That is not needed and it's inappropriate to request it.
I'm sorry you feel that way.
> Please don't try and speak on behalf of another Team
> member. If Metze has issues I'm sure he can speak for
> Metze NACKed removal of the libraries, which is not
> being done (I also NACKed that part of the patchset).
It was still in the branch when I last looked at it, and appears to
still be part of the proposal. In proposing patches, it is quite
irritating to see patches proposed for review that contain elements
still in dispute. WIP branches showing direction are one thing, but a
branch for review should not contain elements that are contentious.
If this is easier to digest, could I express it like this:
Metze seems to have voiced some very similar concerns to myself on this
area of work, and I would like to see my concerns clearly addressed.
However, I and the team generally respects metze's technical judgement
and leadership, and while I hold my concerns and objections, I would
happily defer to his thoughts on this matter.
Finally, I have found that my reaction to this area of work has much
more been due to the *process* and *method* here than the final outcome.
This whole proposal just keeps 'brushing me up the wrong way'. This
isn't a new problem, but suddenly it is most terribly urgent, and
similarly, only one solution is apparently possible, without reasonable
discussion being entered into.
Whenever we get into discussions containing this kind of zeal, when one
party or another on the team *knows* they are right, beyond discussion,
we hurt. We stop listening to each other, we stop looking for workable
compromises, and the ramifications last far longer than that technical
thing we fight over.
Think over the long-term, project-changing impacts of:
- forking Samba4
- nested event loops
- reviews (without tool support)
I'm not saying that the outcome we came to in these is wrong, but the
damage we did to the team while we all dived for reflexive, absolute and
urgent positions did us far more harm than taking proper time to make or
move us to the right/consensus outcome ever would have, or did.
On the flip side, think about how we make major changes well: Think
about the rpc binding_handle work, with a slow boil over Samba providing
a unified way to do RPC despite massively different code bases. Think
about the common schannel layer, the low level smb client layer, or all
the things that meant swapping in winbindd took days, not months.
The more we can do of the latter, the better we will be as a team.
Authentication Developer, Samba Team http://samba.org
Samba Developer, Catalyst IT http://catalyst.net.nz/services/samba
More information about the samba-technical