Should we do separate repositories for the different APIs?

[bstabler]

@e-lo asked:

Where does API / Examples / Gists live?

Preferably in separate repositories, tagged with OMX version #. Currently the APIs of all code are in one place and move forward in commits together. I personally find this messy.

What do you all think about having:
• OMX.r
• OMX.py
• OMX.cpp
• OMX.java
• etc...
all as separate repositories? There are good and bad things about this, but the main issue i see is one of the APIs moving forward w/out volunteers to move forward the other APIs and ended up with stale parts of a repo. The major disadvantage I see is consolidated issue tracking/version control.

[bstabler]

I'm fine (at least for now) with everything in one repo since we don't have a lot of activity.

[billyc]

@bstabler @e-lo @bstabler @toliwaga

I think it's time to split these API's into separate repos. I used to think one repo was fine since it's low-volume, but I've changed my mind. Reasons:

• I want to tag release versions with meaningful and simple labels, without having to resort to using labels like "python-0.3.2"
• Each language API should move forward without affecting the other languages.
• I only want notifications for the file format itself and for Python API bugs/issues

I can post this to the omx mailing list if that is more appropriate.

[e-lo]

yes!

[billyc]

@bstabler @e-lo

So if there is no objection can I just do this? Here's my proposal:

• Have a main repo for the OMX file format and the general wiki
• Have separate repos for each language API and related wiki documentation
• All of these should live under one "umbrella" org for OMX. I don't think osPlanning makes a lot of sense anymore... and I've already checked and see that http://github.com/omxdata would do nicely. I've grabbed that org name just in case we decide to do this.
• Notify the omx mailing list that we're moving things around.
• Leave a landing page at the current location showing where things have been moved so people don't get lost.

What do you think? I can do the pruning on each repo and I think it's pretty easy to transfer the wiki contents as well.

[bstabler]

Well, I'm not sure. For VisionEval, we started to put everything into separate repos, but that made it difficult for everyone (RSG, FHWA, ODOT, OSA, and Volpe) to keep track of the overall effort. So I just recently moved everything back into one repo. I'm concerned about the same issue here. How about we discuss? I agree with a lot of what you want to do, so maybe we just need to talk through a plan?

[e-lo]

I think having it in the same namespace, github/omxdata, mitigates that somewhat and you can maintain a Jekyll landing page in the same place [ which for some people is the only place they will really need to go ]

[bstabler]

@billyc and I chatted and here's the plan:

• Keep this as the main repo for the OMX file format and the general wiki
• Have separate repos under osPlanning for each language API and related wiki documentation
• Consider a future organizational home for this project, such as ActivitySim, Zephyr, or whatever else may emerge in the near future

[billyc]

Python code and Python API docs moved to https://github.com/osPlanning/omx-python -- and the sidebar there still links to the main OMX home page.

I can split the other API's off as well, or the primary maintainers can...? Probably makes sense for me to do it all, right @bstabler ?

[bstabler]

Yep

[billyc]

Done.

• C#: https://github.com/osPlanning/omx-csharp.git
• C++: https://github.com/osPlanning/omx-cpp.git
• Java: https://github.com/osPlanning/omx-java.git
• Python: https://github.com/osPlanning/omx-python.git
• R: https://github.com/osPlanning/omx-r.git

[bstabler]

I updated the documentation in a bunch of places and generally cleaned everything up. I think we're done with this task.