hi, just a few replies in the text below..
First of all, seeing these discussions, I'd like to point out, that nupic should remain/become easy for new-comers to jump in, and fun to use/develop for the community! For the average Joe like me, you just clone, verify that it runs, and develop your garage project. When after 3 weeks you have a free weekend, you try to pull new features and see how it goes. I think those models are for a company "whose business deploys nupic". Then you should become a Grok customer, and let them solve the problems for you. Or atleast hire a student to backport the changes from upstream for you. This is a relation Fedora-RedHat have, and actually the vibrant community and brontosaurus corporate create potential for "providers" like Grok. On Thu, Nov 14, 2013 at 6:51 PM, stewart mackenzie <[email protected]>wrote: > Hi All, > > Response to Marek: > * It really doesn't matter that forking "doesn't follow the git model" > - the git model some say is actually broken - (I agree). What is > important is that you make it painfully easy for the community to use > your software so that your software can spread easily. > Agreed. But the spread should not be at the cost of burden to (community) development. Actually I dont find a need for some read on git, git clone and ./build.sh too much. Esp when this is not a farmville game, but a relatively complex tool. For the easy side, we got lots..linux32, clang, armv6, python2.7, armv7, VMs, cmake is on the way.. if someone makes support for Windows, perfect! But if it required 30% code #ifdef'ed and other rewritten, I;d be saying no, rather start a fork. * Space is cheap, github won't complain. Fork away! > Fork is easy, it;s easier than getting your stuff upstream and going through all the hustle. But imagine we all fork. The development will stop, it;s hard to merge from many others, who will actually care of the merging? And if you get a bugreport to one of the 50 forks, what you do? > * You should have like 10 branches on your local development fork. But > > * Bugfix issues should be created on the stabilization fork. It gives > a clear history of bugfixes associated with it. (then you can cherry > pick if it's pertinent to development and visa versa) > If I got you, you propose two branches - stable for companies w/ bug-fix only. And devel with new features. But what happens when you have a feeling that devel is stabilizing, so you'd like to shift stable=devel, but a new feature arrives in devel? Make devel-devel? Also, no new bugs nor commits to devel don't make it suitable for stable. This is the biggest problem I see with this separate development: Red people develop on hot code, they of course make bugs and iron them. Blue people use the old, reliable, bug free code. Now maintainer of the blue merges a code the reds left 5 months ago, and of course (because by their personality/business they use different sw stack/needs) there're bugs! The maintainer doesn't have to know how to fix 'em, and the reds have long forgotten issues from that time, so it'll all be more complicated. So for a simple transition, use shortest possible deploy-file a bug-fix cycle. Kind regards > Stewart > Best, Mark -- Marek Otahal :o)
_______________________________________________ nupic mailing list [email protected] http://lists.numenta.org/mailman/listinfo/nupic_lists.numenta.org
