I think that poll is a little misleading. We don't want NuPIC to be specific to Grok and I don't think that it is. I think there is some confusion about what is actually in the repository.
What parts of the code are Grok-specific? And what are the plans that will cause backwards compatibility issues? I don't think backwards compatibility needs to slow anything down. With the new SP, for instance, we left the old SP so that people (both at Grok and elsewhere) could gradually migrate on their own. On Fri, Jan 24, 2014 at 1:41 PM, Matthew Taylor <m...@numenta.org> wrote: > I'm interested in what everyone reading this thinks (even those less > vocal). Please take 2 seconds to fill in this simple poll: > > > https://docs.google.com/forms/d/1NVSzx26HQAbTtgZi4BHi0hkbmja9VY70lu-szkgdpsQ/viewform > > Thanks, > > --------- > Matt Taylor > OS Community Flag-Bearer > Numenta > > > On Fri, Jan 24, 2014 at 1:06 PM, Chetan Surpur <cheta...@gmail.com> wrote: > >> I don't have anything concrete to say, but I would like to put in my two >> cents: >> >> >> *1. I think major migrations like this are done most easily in >> incremental, stable steps.* >> >> Every change we make should continue to be fully tested by a regression >> suite, and nothing should break at any point. Even if this philosophy seems >> to extend the migration process, in reality it shortens it because fewer >> things break and need to be fixed. >> >> With that in mind, I support maintaining the Grok dependency through the >> migration. That being said... >> >> *2. I would like to see NuPIC core and all bindings / clients having >> their own regression and CI suites, independent of Grok.* >> >> This should be the goal, regardless of the migration process we choose. >> Grok's test suite should ultimately be only for the Grok client, which >> should be a consumer of the NuPIC core. The NuPIC repos should each have >> their own tests, that the community can maintain along with Grok staff. >> >> >> We can maybe execute on #2 after or independently of #1. This way, we >> achieve both the stability of the transition, while moving towards Grok / >> NuPIC independence. >> >> >> On Fri, Jan 24, 2014 at 11:23 AM, Matthew Taylor <m...@numenta.org>wrote: >> >>> Fergal and Stewart strongly favor breaking away from the Grok dependency >>> for NuPIC Beta, while I am arguing for maintaining it. Maybe we can reach a >>> win-win situation. >>> >>> I'd be comfortable breaking the Grok / NuPIC Beta dependency only if we >>> build up a solid regression test suite that fully encompasses all the >>> current predictive requirements for Grok. This will require me (or someone >>> else from Numenta) understanding and extracting any regression testing done >>> in the current Grok QA pipeline into open source, as well as creating a CI >>> flow that accommodates regression testing. Once that suite is created, we >>> would need to apply it to NuPIC Beta as well as NuPIC Alpha, and only call >>> NuPIC Beta complete once it passes all the regression tests. When we could >>> adjust Grok to run against NuPIC Beta and revalidate that its internal >>> pipeline continues to pass. >>> >>> Creating the regression test suite and populating it with tests will be >>> a considerable amount of work, but the core extraction could be executed >>> somewhat simultaneously. Once there are some solid regressions tests to use >>> as examples, community members could write their own tests within the suite. >>> >>> >>> >>> >>> --------- >>> Matt Taylor >>> OS Community Flag-Bearer >>> Numenta >>> >>> >>> On Fri, Jan 24, 2014 at 10:21 AM, Stewart Mackenzie >>> <setor...@gmail.com>wrote: >>> >>>> I believe weighing core down with Grok is dangerous and will adversely >>>> affect both Grok and Nupic. I might be wrong, but I'm willing to voice my >>>> opinion on this point. I strongly oppose this direction. I will be civil >>>> and acquiesce if the community decides otherwise but essentially I've >>>> removed my gloves in the most gentlemanly of ways. >>>> >>>> Many open source projects will keep the testing code closed. It keeps >>>> the power close. But this is a mistake. The testing code should be released >>>> under the same the license. Release this power, fear not you have the GPL3, >>>> the greatest community license ever. >>>> >>>> core is its own beast, it'll be formed to tightly focus on what it will >>>> be good at. It really doesn't matter about other projects. core exposes >>>> best practises, those applications will accord. The Grok team should stick >>>> to nupic-now and when nupic-core has had several demo applications and once >>>> the community has beaten the API about. Then Grok should accord to core. >>>> >>>> The current components cannot 'snap' together like lego, with a bounded >>>> buffer in-between components, therefore if Grok is a weight. core will most >>>> likely not be able to play Lego. >>>> >>>> Core is a Phoenix rising from its ashes. >>>> >>>> Matthew Taylor <m...@numenta.org> wrote: >>>> >For clarity's sake, let's call the current state of NuPIC "NuPIC >>>> >Alpha", >>>> >and the proposed state of NuPIC (once the C++ core is extracted and >>>> >we've >>>> >solidified the core API) "NuPIC Beta". >>>> > >>>> >Regarding the proposal that Grok continue using the legacy codebase >>>> >(NuPIC >>>> >Alpha) while a copied version is refactored in parallel (NuPIC Beta)... >>>> > >>>> >While this does allow unfettered freedom for us to create exactly the >>>> >architecture we want without worrying about client contracts, it makes >>>> >me >>>> >uncomfortable to have Grok detached from the "development head" of the >>>> >evolving NuPIC project. A solid regression test suite takes a >>>> >considerable >>>> >amount of time to create, and the only form of one we have right now >>>> >runs >>>> >within the Grok QA pipelines. Taking away the Grok dependency >>>> >essentially >>>> >means taking away the only regression testing NuPIC currently has. >>>> > >>>> >If we diverged Grok from NuPIC Beta in this fashion, I would want to >>>> >get >>>> >Grok pointing to the NuPIC Beta architecture ASAP, which would mean >>>> >that if >>>> >any unknown performance changes were introduced during the refactoring, >>>> >they would be exposed only at the point when we started building Grok >>>> >off >>>> >NuPIC Beta. It also means that these problems might be quite hard to >>>> >debug >>>> >and fix, because we won't be able to point to a specific change that >>>> >caused >>>> >the regression failure. And the longer Grok goes without using NuPIC >>>> >Beta, >>>> >the more danger NuPIC Alpha is in of diverging algorithmically from >>>> >NuPIC >>>> >Alpha. >>>> > >>>> >Another reason to keep the Grok dependency is because Grok engineers >>>> >might >>>> >need to make algorithmic changes to NuPIC to support customer >>>> >requirements >>>> >for Grok, in which case they would have to make those changes on NuPIC >>>> >Alpha. These changes would potentially span over the python and C++ >>>> >codebases, and applying these changes to NuPIC Beta at the same time >>>> >would >>>> >have to be done by the NuPIC community, and it could get messy. >>>> > >>>> >If we apply this refactoring in incremental steps, assuring that the >>>> >Grok >>>> >pipeline continues to run and pass along the way, I feel like we'll end >>>> >up >>>> >with a stabler product in the end. I also don't think it will bind our >>>> >hands to make the kinds of API changes the community wants. In fact, I >>>> >think the current C++ API is rather close to fulfilling the needs of >>>> >everyone. If changes to the C++ API are made, we simply update the >>>> >dependent python bindings and client that Grok uses. Grok should not >>>> >have >>>> >to change at all. Other projects the community has created around NuPIC >>>> >would also not need to change, because the python client they are using >>>> >will not mutate. >>>> > >>>> >I don't want Grok to change in response to this refactoring (except to >>>> >update the NuPIC build process due to repository and dependency >>>> >changes). >>>> >NuPIC already has a specific use-case with Grok, and we shouldn't break >>>> >this. We can change the core C++ API all we want, as long as the Python >>>> >client Grok uses doesn't change. >>>> > >>>> >In Summary, I don't want to detach Grok from NuPIC Alpha because: >>>> >- we lose regression testing >>>> >- potential of nasty algorithm merges from NuPIC Alpha by Grok >>>> >engineers >>>> >- the python API currently exposed to Grok by NuPIC Alpha should not >>>> >change >>>> >with NuPIC Beta >>>> >- the extra abstraction layer of the python bindings and client provide >>>> >us >>>> >the flexibility to change the core API however we want >>>> > >>>> > >>>> >--------- >>>> >Matt Taylor >>>> >OS Community Flag-Bearer >>>> >Numenta >>>> > >>>> > >>>> >On Fri, Jan 24, 2014 at 8:52 AM, Fergal Byrne >>>> ><fergalbyrnedub...@gmail.com>wrote: >>>> > >>>> >> Hi Matt, >>>> >> >>>> >> >>>> >> That email was amending its immediate predecessor, where I was >>>> >suggesting >>>> >> a layout for all the nupic.* repos. I'd left out nupic itself as it >>>> >> currently is. >>>> >> >>>> >> My last mail (sent 9.46 this morning my time) supercedes this >>>> >somewhat, as >>>> >> it contains an alternative strategy for the extraction and future >>>> >> development. Essentially what I'm saying is that a total internal >>>> >fork is >>>> >> the safest way to go. This leaves nupic entirely as it is today, and >>>> >makes >>>> >> essentially two copies - one for continuing incremental development >>>> >for >>>> >> Grok's purposes, using a split-out of the existing nupic into >>>> >nupic/nta >>>> >> (C++) and nupic.py.legacy (python); the other for radical and >>>> >user-free >>>> >> development of nupic.core (C++) and nupic.py (bindings, clients). >>>> >> >>>> >> Having to mix Grok's requirements for a stable codebase with the need >>>> >to >>>> >> build a real modular system creates incidental complexity which will >>>> >> severely retard or prevent the success of the new development. >>>> >> >>>> >> This layout allows Grok to pick and choose from new improvements to >>>> >both >>>> >> C++ and python codebases (simply by pulling them in to nupic/nta or >>>> >> nupic.py.legacy), but never to require that the new side continuously >>>> >> passes all the Grok-required tests. >>>> >> >>>> >> Since improvements will either be to one or the other codebase, there >>>> >is >>>> >> no great overhead in managing the expanded list of repos. Grok never >>>> >has to >>>> >> compromise on what goes into nupic, and the community has the freedom >>>> >to >>>> >> make drastic (but planned and orderly) changes to the new >>>> >architecture. >>>> >> >>>> >> Regards, >>>> >> >>>> >> Fergal Byrne >>>> >> >>>> >> >>>> >> On Fri, Jan 24, 2014 at 3:58 PM, Matthew Taylor <m...@numenta.org> >>>> >wrote: >>>> >> >>>> >>> On Fri, Jan 24, 2014 at 1:07 AM, Fergal Byrne < >>>> >>> fergalbyrnedub...@gmail.com> wrote: >>>> >>> >>>> >>>> Insert at top of my list >>>> >>>> >>>> >>>> nupic repo remains with entire current contents >>>> >>>> >>>> >>>> nupic.core etc... >>>> >>>> >>>> >>> >>>> >>> Can you explain this? I don't understand what you're saying. >>>> >>> >>>> >>> --------- >>>> >>> Matt Taylor >>>> >>> OS Community Flag-Bearer >>>> >>> Numenta >>>> >>> >>>> >>> _______________________________________________ >>>> >>> nupic mailing list >>>> >>> nupic@lists.numenta.org >>>> >>> http://lists.numenta.org/mailman/listinfo/nupic_lists.numenta.org >>>> >>> >>>> >>> >>>> >> >>>> >> >>>> >> -- >>>> >> >>>> >> Fergal Byrne, Brenter IT >>>> >> >>>> >> <http://www.examsupport.ie>http://inbits.com - Better Living through >>>> >> Thoughtful Technology >>>> >> >>>> >> e:fergalbyrnedub...@gmail.com t:+353 83 4214179 >>>> >> Formerly of Adnet edi...@adnet.ie http://www.adnet.ie >>>> >> >>>> >> _______________________________________________ >>>> >> nupic mailing list >>>> >> nupic@lists.numenta.org >>>> >> http://lists.numenta.org/mailman/listinfo/nupic_lists.numenta.org >>>> >> >>>> >> >>>> > >>>> > >>>> >>>> >------------------------------------------------------------------------ >>>> > >>>> >_______________________________________________ >>>> >nupic mailing list >>>> >nupic@lists.numenta.org >>>> >http://lists.numenta.org/mailman/listinfo/nupic_lists.numenta.org >>>> >>>> Kind regards >>>> Stewart >>>> >>>> -- >>>> Please excuse my typos and brevity >>>> >>>> _______________________________________________ >>>> nupic mailing list >>>> nupic@lists.numenta.org >>>> http://lists.numenta.org/mailman/listinfo/nupic_lists.numenta.org >>>> >>> >>> >>> _______________________________________________ >>> nupic mailing list >>> nupic@lists.numenta.org >>> http://lists.numenta.org/mailman/listinfo/nupic_lists.numenta.org >>> >>> >> >> _______________________________________________ >> nupic mailing list >> nupic@lists.numenta.org >> http://lists.numenta.org/mailman/listinfo/nupic_lists.numenta.org >> >> > > _______________________________________________ > nupic mailing list > nupic@lists.numenta.org > http://lists.numenta.org/mailman/listinfo/nupic_lists.numenta.org > >
_______________________________________________ nupic mailing list nupic@lists.numenta.org http://lists.numenta.org/mailman/listinfo/nupic_lists.numenta.org
