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 On 10 September 2013 16:44, Matthew Taylor <[email protected]> wrote: > On Tue, Sep 10, 2013 at 12:13 PM, David Ragazzi <[email protected]> > wrote: > > An question I would ask is: how and when pull requests are evaluated. I > see > > many open pull requests (of mine and others) but not (apparent) progress > > with them. > > It's very ad-hoc at the moment, but that's really not the right way of > doing it. I try to make it a point to review open PRs at our sprint > planning meeting, and we've been keeping track of them at Grok daily > Scrums, but this is obviously not enough. > > I've put some pressure on our team to continue to review them, and in > the past couple days, we've at least merged these two: > > https://github.com/numenta/nupic/pull/142 > https://github.com/numenta/nupic/pull/230 > > I also have a view of PRs that provides more detail on them, including > highlighting those that are older than one week: > > http://numenta.org/tools/pullrequests.html > > Internally within Grok/Numenta, we are establishing new build and CI > pipelines around our commercial product, which depends heavily on > NuPIC. It doesn't help us that we have so many unmerged PRs. We were > aware that this could be a detrimental situation ("pull request > graveyard"[1]) from the beginning, and we really cannot let it get any > worse than it is. As a part of our new pipelines, we'll be putting > together Wallboards[2] that display our build status and track certain > metrics, which will include open NuPIC PRs. I hope this will help us > keep up our awareness of this. > > We should at least close the PRs that we don't think are mergeable > within the near future. They can always be resurrected at a later > date, once we're more prepared for them. > > Comments? Suggestions? > > --------- > Matt Taylor > OS Community Flag-Bearer > Numenta > > [1] http://wonko.com/post/yui-from-the-outside > [2] https://www.atlassian.com/wallboards > > _______________________________________________ > 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
