Committed

Yup, thanks!
Also, can we get a JIRA to track down the future removal?

Right. Ok, to commit ?

Continuing the conversation started on BIGTOP-1934, I have linked this JIRA to the appropriate ZK ticket. We clearly need to track the release of ZK 3.5 to remove this patch once it is out.

Well, it is a platform specific one (poor wording on my side, I guess My point still stands: we are making decisions on what to do fix in the upstream and what not. It is fine if we decide to do in the sound mind and not simply as a one-time thing. From the historical standpoint though: we never been doing this and were steering clear of the distribution games so we can remain the only data stack 100% based on Apache genuine released. This stance could be right or wrong, but it is what it is. If we are seeing a need to change it - perhaps it is a time. But I would try to work with ZK community to incorporate the fix into their next release.

Hi Konstantin Boudnik: This is not a vendor specific change, the change is picked from upstream (3.5 branch of zookeeper) . Poor wording from my side.

The patch is removing a machine-specfic and gcc-specfic assembler statement and is replacing it with a gcc specific generic atomic instruction. That's really an improvement.

I don't like this. My main dislike is that we start meddling with Apache released software. I think someone wants a vendor-specific change in the stack's component - they need to work with the community in question. Bigtop releases shouldn't be used as a vehicle to make changes in the upstream.

This is a slippery slope and we should use it with utmost caution: that's why I am generally against patching stuff in our releases.

Use the gcc built in atomic operations rather assembler code