1. Openmama-dev@lists.openmama.org
  2. Messages
   Date   
Re: Subscription Create Behaviour

Frank Quinn
 

Hi Mike,

 

Subscription activations may be created upfront before mama_start if not using the throttle yes.

 

The behaviour you have identified is similar to behaviour outlined in the OpenMAMA Developer’s guide in the MAMA Subscription Callbacks section where it is possible to receive an onMsg before the onCreate has even been fired. It’s the same sort of principle in both cases where the thread performing the setup differs from the thread performing the dispatch. Note I expect the behaviour you have observed will only happen if you’re (quite rightly) not using the default queue for your subscriptions.

 

If you want to prevent this behaviour, adding your own MAMA Queue event to initialized all unthrottled subscriptions when the default queue unblocks could be an option.

 

Cheers,

Frank

Frank Quinn, Cascadium | +44 (0) 28 8678 8015 | http://cascadium.io

 

From: Openmama-dev@... <Openmama-dev@...> On Behalf Of Slade, Michael J via lists.openmama.org
Sent: 17 May 2021 11:02
To: openmama-dev@...
Subject: [Openmama-dev] Subscription Create Behaviour

 

Hi OpenMAMA Dev,

 

I wanted to clarify the expected behavior surrounding creation of subscriptions during application startup – should subscription activations always be executed by the thread dispatching events off the throttle queue?

 

Taking mamalistenc as an example, subscriptions can be created before we start dispatching on the default event queue. If the throttle rate is non-zero, the subscriptions’ activations are added to the throttle queue after the set interval has expired, but will not be executed until we start dispatching on the queue when we call mama_start.

 

The other behavior we see is if the throttle is disabled (the rate is set to <=0). The subscriptions’ activations are executed immediately on the calling thread – ignoring the queue - before the mama_start call due to the below code snippet. This results in the subscription being created on the transport and messages being received from the middleware before the mama_start call. Is this expected/allowed behavior?

 

Throttle.c:

if (self->mRate <= 0.0)

{

    /* throttle is not in use, execute immediately */

    mama_log (MAMA_LOG_LEVEL_FINEST, "wombatThrottle_dispatch (): "

              "no throttle; triggering action.");

    actionCb (closure1, closure2);

}

 

Thanks in advance,

Mike

This message is confidential and subject to terms at: https://www.jpmorgan.com/emaildisclaimer including on confidential, privileged or legal entity information, malicious content and monitoring of electronic messages. If you are not the intended recipient, please delete this message and notify the sender immediately. Any unauthorized use is strictly prohibited.
OpenMAMA OMNM 1.0.0 Released

Frank Quinn
 

Hi Folks,

 

It has been a while since the last release but we’re pleased to announce the release of OpenMAMA OMNM 1.0.0. This release includes:

 

  • Complete interface compatibility with OpenMAMA
  • Complete unit test coverage for all official OpenMAMA unit tests
  • Platform support for all OpenMAMA supported platforms including Windows and OSX
  • A set of methods to support extending omnm for use in other payload bridges with reduced code required:
    • omnmmsgPayloadImpl_[gs]etExtenderClosure to allow the extender
      to attach their own internal object to the omnm payload
    • omnmmsgPayloadImpl_updateVectorMsgPayload to allow the extender
      to update vectors of messages without needing an intermediate
      mamaMsg for each submsg.

Release artifacts can be found here:

https://github.com/cascadium/OpenMAMA-omnm/releases

Or by running:

yum / apt upgrade openmama-omnm

From the OpenMAMA thirdparty repository hosted by our friends at cloudsmith:

https://cloudsmith.io/~openmama/repos/openmama-thirdparty/packages/

The first implementation based on this base bridge will be released soon too and adds support for msgpack.

 

Cheers,

Frank

 

Frank Quinn

Cascadium

T: +44 (0) 28 8678 8015

E: fquinn@...

W: http://cascadium.io

 
Subscription Create Behaviour

Slade, Michael J
 

Hi OpenMAMA Dev,

 

I wanted to clarify the expected behavior surrounding creation of subscriptions during application startup – should subscription activations always be executed by the thread dispatching events off the throttle queue?

 

Taking mamalistenc as an example, subscriptions can be created before we start dispatching on the default event queue. If the throttle rate is non-zero, the subscriptions’ activations are added to the throttle queue after the set interval has expired, but will not be executed until we start dispatching on the queue when we call mama_start.

 

The other behavior we see is if the throttle is disabled (the rate is set to <=0). The subscriptions’ activations are executed immediately on the calling thread – ignoring the queue - before the mama_start call due to the below code snippet. This results in the subscription being created on the transport and messages being received from the middleware before the mama_start call. Is this expected/allowed behavior?

 

Throttle.c:

if (self->mRate <= 0.0)

{

    /* throttle is not in use, execute immediately */

    mama_log (MAMA_LOG_LEVEL_FINEST, "wombatThrottle_dispatch (): "

              "no throttle; triggering action.");

    actionCb (closure1, closure2);

}

 

Thanks in advance,

Mike

This message is confidential and subject to terms at: https://www.jpmorgan.com/emaildisclaimer including on confidential, privileged or legal entity information, malicious content and monitoring of electronic messages. If you are not the intended recipient, please delete this message and notify the sender immediately. Any unauthorized use is strictly prohibited.
OpenMAMA "top level" Common Headers

Frank Quinn
 

Hi Folks,

 

With more and more packaging options being made available to OpenMAMA, it was only a matter of time before the fact that our build system includes top level header files was to become an issue.

 

This was raised by our friends at Microsoft / vcpkg when they discovered that it conflicted with one of their headers.

 

I have suggested a workaround https://github.com/Cheney-W/vcpkg/pull/1 which was ultimately merged upstream, but it involves moving these trailing headers into the “wombat” subdirectory. So that’s:

 

  • destroyhandle.h
  • platform.h
  • list.h
  • lookup2.h
  • property.h
  • timers.h
  • wlock.h

 

Which will all shortly be moved into the wombat subdirectory through our build system when installing.

 

If you make direct use of these headers, to fix this in your code if you use these headers directly, you may simply add $MAMA_ROOT/include/wombat to your include paths (or better still, update your #include statements to use <wombat/>). The former is something you should be able to do now before the change lands so you are forwards compatible with it.

 

This is planned to be included in the next upcoming OpenMAMA release (currently 6.3.2).

 

If anyone desperately wants a configuration option to allow the legacy header location, that can also be considered, though since we’re trying to get included in as many upstream packing targets as possible, it will not be the default for our packaging going forward.

 

Cheers,

Frank

 

Frank Quinn

Cascadium

T: +44 (0) 28 8678 8015

E: fquinn@...

W: http://cascadium.io

 
Re: A new "MamaResourcePool" API for OpenMAMA?

Bill Torpey
 

Hi Frank:

I read with interest your latest email, and certainly agree that there are ways to make OpenMAMA both easier to use (and harder to mis-use!), and more accessible to new users. We've been working on these issues since NYFIX was initially acquired by NYSE back in 2009, and have some experience (and code!) to share as a result.

For us, the biggest problem in moving our middleware stack to Mama/OpenMAMA back in the day (from Tibco Rendezvous), was the relatively poor support for setup and teardown of Mama objects. This wasn't totally surprising, as the typical use case for Mama at the time consisted of relatively long-lived publishers, with subscribers that would come and go during the day. However, in our case the subscribers (servers) tend to be the long-lived components and the publishers (clients) tended to come and go. We had a lot of problems coordinating object lifetimes, especially in a multi-threaded environment, such that we avoided memory leaks, or even worse errors such as use-after-free.

At the time, we worked with the Mama development team to create a wrapper layer called "MME" (for MAMA Managed Environment) which would manage the lifetimes of Mama event objects and remove the biggest problem in Mama: the requirement that object destruction occur only on the event dispatching thread. At the time, we hoped that MME would become part of Mama proper, but that never happened and the rights to the code were transferred to NYFIX when NYSE divested both NYFIX and SR Labs. NYFIX released the code as open-source concurrent with our release of OZ at https://github.com/nyfix/MME.

We've been using MME in the NYFIX Marketplace since approximately 2010; first with the commercial transport from SR/Vela, and for the past year and change with OZ (https://github.com/nyfix/OZ), the open-source transport that we created based on ZeroMQ.

We would be interested in working with the OpenMAMA community to extend and improve MME, and suggest that it answers several of the issues you mentioned.

One thing that MME does not address, however, is overall ease-of-use, and specifically the steep learning-curve associated with the Mama API. For that, we'd like to suggest that the community take a look at the example code included with OZ (https://github.com/nyfix/OZ/blob/master/examples/Readme.md). The example code encapsulates a lot of the "tricky bits" associated with the Mama API, enabling someone to get started quickly -- for example, see https://github.com/nyfix/OZ/blob/master/examples/sub.cpp.

Full disclosure: the OZ examples are exclusively C++ -- while the OZ transport itself is written in C, we prefer C++ for application-level code. The OZ examples do, however, work with other transports, specifically the (now deprecated) Qpid transport.

Both MME and OZ are tried and tested in production use, which is potentially a significant advantage. In any event, we'd be delighted to engage with the OpenMAMA community around either or both of these components to see how they could possibly address some or all of the important issues you raise. We hope the community will take the time to explore both MME and OZ, and we're very interested in any feedback.

Best Regards,

Bill Torpey
A new "MamaResourcePool" API for OpenMAMA?

Frank Quinn
 

Hi Folks,

 

We are currently considering options for trying to make the OpenMAMA API easier to work with and more accessible for new users.

 

When I look at the OpenMAMA API's strengths and weaknesses, the setup and management of the subscriptions themselves is one of the more difficult things to manage especially with a new user. These are things which we seasoned users would take for granted but I think new users would struggle with.

 

That is why I'm suggesting a new "MamaResourcePool" api.

 

The idea is to manage OpenMAMA resources via OpenMAMA itself rather than depending on the user to manage complex state, setup, shutdown etc. I'm taking the approach of starting with what I (pretending to be a new OpenMAMA user) would like to see as opposed to things which would be technically easier to do etc.

 

So taking for example a new subscription, this is the entire code I'm proposing (in C here but should translate easily to other languages) should be required:

 

// Set up the event handlers for OpenMAMA

mamaMsgCallbacks callbacks;

memset(&callbacks, 0, sizeof(callbacks));

callbacks.onMsg = subscriptionOnMsg;

callbacks.onCreate = subscriptionOnCreate;

callbacks.onError = subscriptionOnError;

 

// Use a new "resource pool"

mamaResourcePool resourcePool;

const char* poolName = NULL;

const void* closure = NULL;

 

// Create the resource pool, allocating queues, defaults etc from configuration

mamaResourcePool_create(&resourcePool, poolName);

 

// Actually... subscribe to something via something convenient like a URI

mamaResourcePool_createSubscriptionFromUri(&subscription, "bridge://transport/source/topic", &callbacks, closure);

 

// Block

mama_start();

 

And then you would start receiving events. No transport creation, source creation, queue creation, encouraging users use default queue etc.

 

I’d also suggest that the callbacks onCreate and onError should be optional, with the default implementation simply logging those events.

 

I foresee similar with lambdas etc. The idea is that mamaResourcePool will:

 

·         When it is created:

o    Create a number of event queues for subscriptions (which could be configurable in properties based on the poolName)

o    Load all payload and middleware bridges found on the PATH / LD_LIBRARY_PATH etc

o    Call mama_open() (if not already open)

o    Create and manage internal stores of all managed subscriptions, transports, sources etc

·         Then when a resource is created inside:

o    Find / create transport bridge

o    Find / create transport

o    Find / create source

o    Find / create subscription (e.g. multiple callbacks for same subscription)

o    Find / create anything which is required to acquire the requested resource

·         Be convenient and usable, but still flexible (it would return existing OpenMama objects so they can be manipulated)

·         Take the heavy lifting and thread safety pain away from the application developer

·         Defer default "is this basic sub" or "is this market data sub" to the bridge, configuration or as an API call in the resource pool itself

 

My guess is that many of you may already have an API that does this in each of the provided languages… but newcomers won't have that. This would vastly reduce the complexity and error checking required for a new user, as well as remove the expectation around deciding “which subscription API to use” from the application developer.

 

If there is any feedback to this approach, or in particular if anyone has recently worked with a new user coming online with OpenMAMA please let us know or pop into Gitter to discuss!

 

Cheers,

Frank

 

Frank Quinn

Cascadium

T: +44 (0) 28 8678 8015

E: fquinn@...

W: http://cascadium.io

 
OpenMAMA Now Available on Homebrew (Mac / Linux)

Frank Quinn
 

That’s right Mac users – OpenMAMA has been approved and is now included in homebrew’s set of packages.

 

So to install OpenMAMA on a Mac, simply

 

brew update

brew install openmama

 

…and yes this will also work on the new Apple M1 machines.

 

This also has been verified as working with linuxbrew (if anyone uses that).

 

Any issues please raise an issue on the OpenMAMA github page!

 

Cheers,

Frank

 

Frank Quinn

Cascadium

T: +44 (0) 28 8678 8015

E: fquinn@...

W: http://cascadium.io

 
Re: The future of CentOS and OpenMAMA

Bill Torpey
 

Hi Frank:

At NYFIX we not too long ago moved from RH to CentOS 7 for our dev and prod installs, and assumed that CentOS 8 would be our eventual upgrade path.  

It’s way too early to say how things shake out, with the exception that we will certainly NOT be moving to CentOS 8 Stream.

Personally I’ve moved my day-to-day development from CentOS to Ubuntu, and I’m quite happy with it.  I now only use CentOS to regression test before pushing changes.

Hope this helps.

Regards,

Bill



On Feb 24, 2021, at 12:34 PM, Frank Quinn <fquinn@...> wrote:

Hi Folks,
 
I’m curious about the community feeling towards the future of CentOS. I’d appreciate a reply with one or a selection of the following for those of you running Red Hat derivative distributions:
 
  1. We will be clinging onto CentOS 7 for dear life since CentOS 8 will be EOL 2021 but CentOS 7 won’t be EOL until 2024
  2. We will be making the jump to CentOS Stream
  3. We will go with one of the CentOS clones
  4. We will bide our time and wait to see which CentOS clone comes out on top
  5. This doesn’t really affect us – we use RHEL everywhere
 
Cheers,
Frank
 
Frank Quinn
Cascadium
T: +44 (0) 28 8678 8015
 
The future of CentOS and OpenMAMA

Frank Quinn
 

Hi Folks,

 

I’m curious about the community feeling towards the future of CentOS. I’d appreciate a reply with one or a selection of the following for those of you running Red Hat derivative distributions:

 

  1. We will be clinging onto CentOS 7 for dear life since CentOS 8 will be EOL 2021 but CentOS 7 won’t be EOL until 2024
  2. We will be making the jump to CentOS Stream
  3. We will go with one of the CentOS clones
  4. We will bide our time and wait to see which CentOS clone comes out on top
  5. This doesn’t really affect us – we use RHEL everywhere

 

Cheers,

Frank

 

Frank Quinn

Cascadium

T: +44 (0) 28 8678 8015

E: fquinn@...

W: http://cascadium.io

 
Goodbye Appveyor, Hello Github Actions

Frank Quinn
 

Hi folks,

I am in the final stages of the effort to migrate from Appveyor to Github Actions. This will reduce the overall build time down from 5 hours to 40 minutes across 14 different development environments including new support for OSX in continuous integration. It also provides much richer options around bringing our own compute should we need to with better support for parallel jobs.

These changes will also (finally) retire the Scons build system so if you are still using it, please use cmake instead as documented here:

https://openmama.finos.org/openmama_build_instructions.html

This will be dropping into the "next" branch at some point over the weekend if anyone finds any issues please let me know!

Cheers,
Frank
CentOS 6 / RHEL 6 Support (Reply Needed)

Frank Quinn
 

Hi Folks,

 

CentOS 6 is reaching its main EOL on the 30th November (10 days time), so I’d like to ask the community where they are in respect to migration.

 

Please feel free to reply to me either directly or via list with one of the below:

 

  1. CentOS 6? How quaint. Kill it with fire.
  2. We are moving off CentOS 6 and expect to be migrated away from it before the next OpenMAMA release in Spring.
  3. I think we’d need CentOS support for at least another year or so until all our systems migrate.

 

Cheers,

Frank

 

Frank Quinn

Cascadium

T: +44 (0) 28 8678 8015

E: fquinn@...

W: http://cascadium.io

 
OpenMAMA contribution to FINOS

Frank Quinn
 

Hi Folks,

 

I am excited to announce that OpenMAMA was successfully contributed to FINOS and it's now available as a FINOS hosted project at https://github.com/finos/OpenMAMA. Any old links and git clones should automatically redirect, but if there are any issues with this please let us know.

 

Our website is now hosted at openmama.finos.org and you can reach out to the project team using any of the channels on our support page.

 

Being part of FINOS gives OpenMAMA a specialist target audience to tap into, and helps raise the visibility and profile of the project directly to where it’s likely to be most relevant. We are hoping it will help continue to drive forward with our core goals of adoption, interoperability and visibility.

 

Many thanks to the FINOS team and to the wider FINOS Community for their warm welcome and support in moving OpenMAMA to its new home!

 

Cheers,

Frank

 

Frank Quinn

Cascadium

T: +44 (0) 28 8678 8015

E: fquinn@...

W: http://cascadium.io

 
Announcing OZ: a production-quality, open-source transport for OpenMAMA using ZeroMQ

Bill Torpey
 

Everyone on this mailing list is already well acquainted with OpenMAMA's awesome-ness, but I want to let you know about something that makes OpenMAMA even more awesome.

One thing that has always been a trouble spot for OpenMAMA is the lack of a reliable, high-performance, open-source transport library. The AVIS bridge was little more than a toy, and while the Qpid bridge was an improvement, there has never been a production-quality, open-source transport bridge for OpenMAMA.

Until now.

NYFIX, a division of Itiviti AB, has recently released an open-source transport for OpenMAMA based on ZeroMQ which we are calling OZ. OZ has been in live production use supporting the NYFIX Marketplace since early March in our data centers in Europe, Asia and the U.S., processing roughly 50 million messages per day.

OZ was designed to support many of the most popular features of typical MOM's:

  • publish/subscribe messaging using topic-based addressing, supporting hierarchical topic namespaces and "wildcard" subscriptions;
  • request/reply (inbox) messaging for transactional interactions;
  • dynamic service discovery with minimal configuration;
  • broker-less architecture for reduced latency and optimum throughput;
  • self-describing messages (thanks to OpenMAMA-omnm).

We recently published a whitepaper describing OZ, but the more technical-minded will probably prefer to check out the docs and/or take a look at the sample code. (In particular, the examples use modern C++ constructs to provide a kinder, gentler introduction to OpenMAMA).

We're hopeful that the OpenMAMA community will find OZ helpful, and we look forward to working with everyone in the community to make OZ, and OpenMAMA itself, even better. We encourage everyone to check out OZ at https://github.com/nyfix/OZ.

Please contact me directly or raise an issue with any comments, suggestions, etc.
OpenMAMA 6.3.1 Released

Frank Quinn
 

Hi Folks,

 

We are pleased to announce OpenMAMA 6.3.1 is finally here and has now propagated to Cloudsmith, Maven central etc!

 

This is a maintenance release which fixes several outstanding bugs and introduces some new functionality.

 

  • Added experimental .NET core support (including C# on Linux)
  • Updated supported platforms to include CentOS 8, Ubuntu 18.04 LTS and Ubuntu 20.04 LTS
  • Added quickstart / start of tutorial code for all languages
  • Modernized JNI implementation to use javac -h rather than javah
  • Added json and normalized string methods for all language bindings (formerly reserved for only C)
  • Fix multithreaded builds in OpenMAMA and add "experimental" cloudsmith repository automatic upload
  • Added support for clang sanitizers
  • Added code for creating your own Vagrant box for OpenMAMA (and we uploaded our own)
  • Added ansible code for creating a demo environment
  • Fixed a few race conditions, leaks and bugs
  • Improved Mac Support

 

For a complete list of all 21 issues included in this release, please see here: https://github.com/OpenMAMA/OpenMAMA/milestone/11?closed=1

 

Cheers,

Frank

 

Frank Quinn

Cascadium

T: +44 (0) 28 8678 8015

E: fquinn@...

W: http://cascadium.io

 
Re: OpenMAMA 6.3.1 RC1 Released

Frank Quinn
 

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!


On Thu, 24 Sep 2020, 18:32 Frank Quinn, <fquinn@...> wrote:

Hi Folks,

 

We (finally) have a new RC ready for testing with compiled artifacts for supported platforms – check it out:

 

https://github.com/OpenMAMA/OpenMAMA/releases/tag/OpenMAMA-6.3.1-rc1

This is a maintenance release which fixes several outstanding bugs and introduces some new functionality.

  • Added .NET core support (includig C# on Linux)
  • Updated supported platforms to include CentOS 8, Ubuntu 18.04 LTS and Ubuntu 20.04 LTS
  • Added quickstart / start of tutorial code for all languages
  • Modernized JNI implementation to use javac -h rather than javah
  • Added json and normalized string methods for all language bindings (formerly reserved for only C)
  • Fix multithreaded builds in OpenMAMA and add "experimental" cloudsmith repository automatic upload
  • Added support for clang sanitizers
  • Added code for creating your own Vagrant box for OpenMAMA (and we uploaded our own)
  • Added ansible code for creating a demo environment
  • Fixed a few race conditions, leaks and bugs
  • Improved Mac Support

For a complete list of all 21 issues included in this release, please see here: https://github.com/OpenMAMA/OpenMAMA/milestone/11?closed=1

The first RC stage will last for 2 weeks, so if no major issues are found, we will provide the GA release on Monday 12th October 2020.

 

Good hunting.

 

Cheers.

Frank

 

Frank Quinn

Cascadium

T: +44 (0) 28 8678 8015

E: fquinn@...

W: http://cascadium.io

 
New OpenMAMA Website is Live!

Frank Quinn
 

Hi Folks,

 

After a successful testing period (thanks to all who were involved), we are delighted to announce the official launch the new OpenMAMA website which went live yesterday evening: https://openmama.org

 

We will be getting the word out on social media so please like / share our posts to extend our reach! Also please update any existing links etc. to the OpenMAMA website where appropriate.

 

The site is a complete overhaul and has several key improvements over the former site beyond aesthetics:

 

  • It is responsive
  • It is a static, bloat-free website so it should load very quickly
  • You can submit your own suggested changes to the site via pull request because it's all on github
  • It merges the documentation and main marketing website into one
  • It generally tries to de-duplicate information and the content has had a general refresh

 

If there are any issues please raise them at https://github.com/OpenMAMA/openmama.github.io/issues and we hope you enjoy the new site! As usual, we’ll be keeping an eye on gitter if you have any immediate feedback / concerns.

 

Cheers,

Frank

 

Frank Quinn

Cascadium

T: +44 (0) 28 8678 8015

E: fquinn@...

W: http://cascadium.io

 
OpenMAMA 6.3.1 RC1 Released

Frank Quinn
 

Hi Folks,

 

We (finally) have a new RC ready for testing with compiled artifacts for supported platforms – check it out:

 

https://github.com/OpenMAMA/OpenMAMA/releases/tag/OpenMAMA-6.3.1-rc1

This is a maintenance release which fixes several outstanding bugs and introduces some new functionality.

  • Added .NET core support (includig C# on Linux)
  • Updated supported platforms to include CentOS 8, Ubuntu 18.04 LTS and Ubuntu 20.04 LTS
  • Added quickstart / start of tutorial code for all languages
  • Modernized JNI implementation to use javac -h rather than javah
  • Added json and normalized string methods for all language bindings (formerly reserved for only C)
  • Fix multithreaded builds in OpenMAMA and add "experimental" cloudsmith repository automatic upload
  • Added support for clang sanitizers
  • Added code for creating your own Vagrant box for OpenMAMA (and we uploaded our own)
  • Added ansible code for creating a demo environment
  • Fixed a few race conditions, leaks and bugs
  • Improved Mac Support

For a complete list of all 21 issues included in this release, please see here: https://github.com/OpenMAMA/OpenMAMA/milestone/11?closed=1

The first RC stage will last for 2 weeks, so if no major issues are found, we will provide the GA release on Monday 12th October 2020.

 

Good hunting.

 

Cheers.

Frank

 

Frank Quinn

Cascadium

T: +44 (0) 28 8678 8015

E: fquinn@...

W: http://cascadium.io

 
Re: OpenMAMA Preview Website Launch

Frank Quinn
 

Hi Folks,

 

Quick reminder about the invitation below, and to thank everyone who has checked it out already (I can see a noticeable increase in traffic since sending this out so I know you folks are looking).

 

Particular thanks to our friends at Solace who submitted the first ever pull request to the new website! Others are welcome if appropriate!

 

Cheers,

Frank

Frank Quinn, Cascadium | +44 (0) 28 8678 8015 | http://cascadium.io

 

From: Openmama-dev@... <Openmama-dev@...> On Behalf Of Frank Quinn via lists.openmama.org
Sent: 21 September 2020 09:40
To: openmama-dev@...
Subject: [Openmama-dev] OpenMAMA Preview Website Launch

 

Hi Folks,

 

It is with great pleasure that I can declare that a new website is on its way.

 

It is currently hosted at https://openmama.github.io as a preview version (the former documentation website address) and therefore I invite the members of the mailing list to have a look, and report any issues back directly to be before its "proper" launch to openmama.org on Monday 28th September.

 

The site is a complete overhaul and has several key improvements over the former site beyond aesthetics:

 

  • It is responsive
  • It is a static, bloat-free website so it should load very quickly
  • You can submit your own suggested changes to the site via pull request because it's all on github
  • It merges the documentation and main marketing website into one
  • It generally tries to de-duplicate information and the content has had a general refresh

 

Anyway if there are any issues please raise them at https://github.com/OpenMAMA/openmama.github.io/issues and I hope you enjoy the new site! As usual, I’ll be keeping an eye on gitter if you have any immediate feedback / concerns.

 

Cheers,

Frank

 

Frank Quinn

Cascadium

T: +44 (0) 28 8678 8015

E: fquinn@...

W: http://cascadium.io

 
OpenMAMA Preview Website Launch

Frank Quinn
 

Hi Folks,

 

It is with great pleasure that I can declare that a new website is on its way.

 

It is currently hosted at https://openmama.github.io as a preview version (the former documentation website address) and therefore I invite the members of the mailing list to have a look, and report any issues back directly to be before its "proper" launch to openmama.org on Monday 28th September.

 

The site is a complete overhaul and has several key improvements over the former site beyond aesthetics:

 

  • It is responsive
  • It is a static, bloat-free website so it should load very quickly
  • You can submit your own suggested changes to the site via pull request because it's all on github
  • It merges the documentation and main marketing website into one
  • It generally tries to de-duplicate information and the content has had a general refresh

 

Anyway if there are any issues please raise them at https://github.com/OpenMAMA/openmama.github.io/issues and I hope you enjoy the new site! As usual, I’ll be keeping an eye on gitter if you have any immediate feedback / concerns.

 

Cheers,

Frank

 

Frank Quinn

Cascadium

T: +44 (0) 28 8678 8015

E: fquinn@...

W: http://cascadium.io

 
Re: Proposal: OpenMAMA Default Branch change to "next"

Frank Quinn
 

Hi Folks,

 

The default branch for OpenMAMA has now been set to “next”. Looks a little more lively already 😊

 

If anyone runs into any issues, let me know. Hopefully overall this will make things a little easier.

 

Cheers,

Frank

Frank Quinn, Cascadium | +44 (0) 28 8678 8015 | http://cascadium.io

 

From: Openmama-dev@... <Openmama-dev@...> On Behalf Of Phelan, Nigel via lists.openmama.org
Sent: 25 August 2020 12:49
To: openmama-dev@...
Subject: Re: [Openmama-dev] Proposal: OpenMAMA Default Branch change to "next"

 

Sounds quite sensible to me, Frank.

 

Nigel

 

Nigel Phelan | Corporate & Investment Bank | Market Data Services | J.P. Morgan

 

From: Openmama-dev@... [mailto:Openmama-dev@...] On Behalf Of Frank Quinn
Sent: 25 August 2020 12:35
To: openmama-dev@...
Subject: [Openmama-dev] Proposal: OpenMAMA Default Branch change to "next"

 

Hi Folks,

 

I would like to propose that we change the OpenMAMA github default git branch to “next” instead of “master”.

 

This would mean that:

 

  • When you visit our github page, you will see the latest development code and documentation
  • When you clone the repository, you no longer need to change branch before making feature branches which will eventually become pull requests.

 

Note all existing clones etc would remain unchanged so this won’t actually “break” anything for existing OpenMAMA developers.

 

The rationale being that “master” is reflective of the last stable release, but it’s also the source of the main README output when visitors come to the github page which makes it look like the project is less active than it actually is, repo documentation effectively slows down to match the biannual release cycle etc.

 

The industry in general is also gradually moving away from the “master” nomenclature for branches with linux and github both making noises about moving away from defaulting to that branch name, so this would pave the way for eventual retirement of the branch name (which is actually fine - we can just use our release branches instead as we already do with minimal impact).

 

If anyone has any comments or feedback on this, please respond on this thread.

 

Cheers,

Frank

 

Frank Quinn

Cascadium

T: +44 (0) 28 8678 8015

E: fquinn@...

W: http://cascadium.io

 

This message is confidential and subject to terms at: https://www.jpmorgan.com/emaildisclaimer including on confidential, privileged or legal entity information, malicious content and monitoring of electronic messages. If you are not the intended recipient, please delete this message and notify the sender immediately. Any unauthorized use is strictly prohibited.
1 - 20 of 2305