I honestly think you should keep it simple and start with just Travis-CI and AppVeyor, which will cover your major deployment platforms: OS X, Linux, & Windows. There are old travis-ci config files in the history of the repos you could reference. They contain configurations for both OSX and Linux.
We added bamboo with the intention of eventually doing everything in bamboo, which was a bit of a stretch goal that we haven’t accomplished. That being said, it comes in quite useful for releases and deployments. We’ve automated a lot of things in our pipeline with bamboo. If you think it would be useful, I think I could turn over some bamboo resources for community usage, although I can’t help set up services.
Found an unexpected problem, TravisCI builds for OSX take ages to start, seems to be known problem
I have a working PR, but will have to move to CircleCI for that reason with OSX (need to shoot them an email to get the OSX for free for OSS projects…)
Logged in to CircleCI with my github name (breznak), but I cannot set it up for htm-community/nupic.cpp , as I’m not an “org admin”, as the Circle requests. @rhyolight will have to do that, please.
That’s great, @breznak!! A couple of the badges are still pointing to the old nupic builds though (travis & circleci). Let me know when you get all building and green for by cpp & py, then I’d like to announce this project officially on the #nupic forum (if you like).
I hope everyone else is one board here? @chhenning@heilerm ? I think this is a great direction forward for you guys. Marek knows nupic better when anyone outside Numenta, and he’s an experienced committer on the project.
@David_Keeney had a fork with upgrades to Python 3, which was good. So I was looking at working on that.
@chhenning then had a brand new repository with a lot of good stuff, which was good, but different - arguably a better, more modern approach - but not a fork. So I was looking at working on that.
Now we have official community forks, and their structures are different from the single repository @David_Keeney, @chhenning, and I agreed on. That’s fine, just another pivot. Now I’m looking at working on that. Is @David_Keeney merging his fork into that? What’s happening to @chhenning’s stuff? Are we using multiple repositories now, or is that still up in the air.
I’ll have to get caught up with the plan for those forks. I have no idea what to work on or where. It’s a little hard to track this plan on the forum in its current format. Wouldn’t the Github issue tracker and wiki be better to fold into, now that we have community forks? It’s hard to get into anything with this much volatility. Link to that/those in a pinned thread in the community fork forum?
Basically I’d just like to ensure continuity for you and all other people who base their work on nupic.core forks.
The intention is not to get anyone’s (to a managable degree) work lost, that’s why I discussed with @chhenning to rebase (fork) his Py3 work on top nupic.core.
I’m trying to maintain the htm-community/nupic.cpp repo which has tests and functionality same (or better in the future) as the original Numenta’s.
Currently the tests and builds are available there. And I have some little fixes to code scattered there.
We’ll be working with Christian to merge his code drop into that repo in more understandable (smaller) pieces.
After that would come @David_Keeney 's work on bindings and C# (and others) clients.
TL;DR which fork currently to base your work on? If you depend on py3 stuff, use
If it’s not related, go with
which is basically nupic.core for now.
Actually, this bazaar is a great example of a situation I want to avoid: everyone jumps their fork but the work then becomes incompatible. So I suggest we’d try to merge all the new features iteratively into a common community repo. It’s also easy to add commiters and maintainers there to keep it running.