[PATCH] ctdb-server: Remove one-line goto

[Jeremy Allison]

On Fri, Mar 16, 2018 at 07:59:19AM +0100, Swen Schillig via samba-technical wrote:
> 
> Anyhow, your interpretation is pretty accurate, I'm new to the project,
> trying to find my way through and might be too hard on the list in
> doing so.
> 
> But I have to say, the SAMBA team is not making it too easy either.

Sorry for that. It's not intentional.

> Sometimes certain (coding-)practices are OK and sometimes they're evil.
> Sometimes a patch is too big and sometimes too small to be worth it.
> Sometimes README.Coding is the bible and sometimes the bible is wrong.
> Some say, do one-liner-cleanups "while-at-it" fixing stuff others say
> patches need to fix/change one thing at a time. 
> 
> I know, not all projects out there do things the same way, but it would
> be a lot easier if SAMBA could be slightly more consistent in its
> opinions/rules. # Opening the door to get flooded by disagreements.
> 
> Regarding bike-shedding and cleanups vs real bugfixes.
> I recently sent in 3-4 patches for the s3 area, guess which one got the
> most attention and is pushed already while the "mem leak" one is still
> sitting there :-)

Ping me again and resend the memleak patch. I'll try and take
a look.

> As for the cleanup-only patches, I asked before sending my first one,
> how the SAMBA team handles/wantd those and I heard they're very
> welcome, especially if they reduce LOC.
> 
> I'm not complaining, just saying.
> So, please go easy on me, I'm usually getting around pretty quick and
> won't bother you guys anymore...at least not more than others :-)

I can try and explain part of the problem.

People who are very competent tend to have a harder time
getting into Samba in part because we realize rather
quickly that you are competent, and thus start to expect
more of you than someone who sends in random occasional
patches.

It tends to go like this:

1). Security report - highest priority - Team will jump
on it and write the code/work with the reporter to write
the code.

2). Crash bug - Team will jump on it and if needed rewrite
a patch to get it in asap (I *hate* crash bugs :-).

3). Feature addition - takes longer and often Team members
interested will work to integrate the feature, re-writing
as needed. Some bikeshedding can occur here, mostly around
ensuring there are regression tests.

4). Standard bug fix - bikeshedding can happen here. If
someone is ovbviously competent then we tend to push back
to get them to fix it "the right way". Problem is there
is no one "right way" :-).

5). Code cleanup - bikeshedding tends to happen most
here :-). All the annoying elements of #4 also apply here.

6). Reformatting - no one likes to work on this :-).

Right now your patches fit mostly in #4 and #5, so
I'm afraid you're getting the worst of it.

Please bear with us, we (mostly:-) are really nice
people and we'd love to help you help us - with the
ultimate goal of adding you to the Team so you can
be a nice person yourself :-) :-).

Sorry,

	Jeremy.