Hi folks, I have recently been giving some thought to our currently supported Linux platforms which we package. I would be of the mind that: 1. We should drop Fedora packaging. No-one seems to use it

Hi folks - a reminder that we are going into the final week of this RC -if any major issues are spotted please raise as a priority!

Thanks Igor, This was part of Vela's DQ strategy changes - Aaron could you have a look please? Cheers, Frank

My bad (though a little concerning that passed unit tests - mental note taken to add a test around that) - try again now. Cheers, Frank

Hi folks, I have just submitted a change which should resolve this issue, but worth a check in your code to verify it has fixed the issue for your use case. It's in the "next" branch. Cheers, Frank

Thanks Aaron, Just on the plugin-only front, I'll probably appreciate more what you mean when a pull request comes in, but it's my opinion that if the plugin code isn't flexible enough to allow us to

Thanks Aaron, Put in a few changes to the document to make the prototypes "pop" a little bit more. A few suggestions / talking points though: mama_status dqstrategyMamaPlugin_transportPostCreateHook (

Thanks Aaron, Apologies for the delay in getting to read this properly - for reference to the group this is the link to the document: https://openmama.github.io/openmama_rfc_source_discovery.html From

Hi Bill, Sure sounds good, though these are MAMA bridge level configurations so let's make it: mama.middleware.<id>.unload_on_close=true|false and mama.payload.<id>.unload_on_close=true|false Similar

I have been quite receptive to your concerns - just not your proposed solution which I think is too coarse. Checking if something exists before trying to access it within a framework is far from a hac

On the contrary I welcome OpenMAMA forks If you want to fork and maintain all fixes etc from the upstream that's entirely your decision and part of the beauty of Open Source software. More power to yo

@Yury: The short answer is that we can't, but we can check if a bridge is still open before attempting to access bridge dependant methods in finalisers / destructors which was my suggestion.

Hi Bill, We close the bridges because we leak memory if we dont. Imho leaking memory should be avoided where possible. In this case, its avoidable, so I don't think we should do it. If you really want

Happy holidays folks! First of all (with respect to the C++ concerns), that ticket is still open - I plan on actioning it I just haven't had time yet. My suggestions were far from "don't solve it" and