Guys, A certain amount of direct communication always needs to occur between developers to avoid nasty merges. The SCM system's merging tools can only do so much for us. One way to mitigate this situation is to create tickets in our issue tracking system before you start any significant work. If everyone is doing this, there would be a central location to find out who is working on what issues.
I would encourage everyone wanting to work on NuPIC to create tickets to describe any work you're planning on doing. Feel free to write a note to the ML as well, especially if you think it's something that others might be working on. If you are working on a ticket, mark it to "In Progress" and add it to the current sprint. For example, David, you are working on NPC-300. If you go to our agile board[1], you can move this ticket from "To Do" into the "In Progress" column of the page simply by dragging it over. --------- Matt Taylor OS Community Flag-Bearer Numenta [1] https://issues.numenta.org/secure/RapidBoard.jspa?rapidView=2&selectedIssue=NPC-300 On Tue, Sep 10, 2013 at 5:04 PM, Marek Otahal <[email protected]> wrote: > Hi Dave, > > I quite agree with you..git is pretty smart at this-merging changes to a > single files, and conflicting lines can be nicely shown. Of course, it's > the matter of who gets merged first and the other PR needs rework > (actually, if the code is not too tricky, this is usually work of the repo > manager). > > The situation with CMake is trickier as the files are new (but related to > Makefiles), so git doesn't trigger any conflicts and the files need to be > re-read by hand (eye) again carefully. I suggest two solutions to this: > merge cmake stuff early in (even if not used yet), keep using makefiles and > ask anyone changing some logic in makefile to fix the change in cmake too > (or atleast #TODO it). > Other way would be you ignore the (more or less) minor changes in master > for now, and when you feel ready we all reread the files and try to spot > differences and fix them.. > > With best regards, Mark > > > On Wed, Sep 11, 2013 at 12:53 AM, David Ragazzi <[email protected]>wrote: > >> Hi Matt and Mark, >> >> My fear is the famous "war of commits". In my case with CMake, I spent >> several hours (to not say weeks) working on convert Autotools files to >> CMake in addition to port Nupic c++ files to Windows. However repo state >> changes everyday, and so CMake files (that still are in PR) couldn't >> accommodate these future new changes (a new file, some new build flag, >> etc). So rework is inevitable until CMake PR being finally analysed. >> >> My suggestion (from my brief experience with open-source) to avoid >> rework: >> - You could group PR by function (ex: build, core algorithm, support >> code, etc) and rank them according that they are delivered to you in order >> that a PR don't makes conflicts with others. Ex: someone create a pull >> request changing some simple compiler flags, however there's already an >> another PR that change 80% of the same Makefile with this flag. If the >> commit of the first developer is accepted (even he requested later), the >> second one will have to rewrite his Makefile to accommodate this new change >> (what means compare file to file in order to avoid loose code). But if the >> commit of the first developer is accepted, then we have a logical and fair >> sequence and so we avoid loose code in this "war". I mean we could have a >> FIFO (first in, first out) sequence for analysis of pull requests (when >> convenient, of course). >> >> Only my suggestion, please do not get me wrong. >> >> Best regards, David >> >> -- > Marek Otahal :o) > > _______________________________________________ > nupic mailing list > [email protected] > http://lists.numenta.org/mailman/listinfo/nupic_lists.numenta.org > >
_______________________________________________ nupic mailing list [email protected] http://lists.numenta.org/mailman/listinfo/nupic_lists.numenta.org
