> On May 7, 2015, 6:34 p.m., Ben Mahler wrote: > > Hm, I looked at MESOS-2633, that's only about moving implementation out? > > > > Could we get some more context on this change? What motivated it? Is there > > a bug? When can it occur? What happens if it does?
There was no Jira about this change: it was a TODO in the code, which I thought looked trivial enough that was worth doing (my general rule has always been: if it takes longer to create a ticket than actually writing the code to solve it, just do it :) As for the reasons for the ToDo in the first place, I'll leave it up to @adam to address that - I was merely executing on his wishes... Thanks for noting that, though: I have updated the description and elaborated on the diff description. - Marco ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/33490/#review82867 ----------------------------------------------------------- On May 8, 2015, 6:16 p.m., Marco Massenzio wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/33490/ > ----------------------------------------------------------- > > (Updated May 8, 2015, 6:16 p.m.) > > > Review request for mesos, Adam B and Joris Van Remoortere. > > > Repository: mesos > > > Description > ------- > > In `Framework::addCompletedTask(const Task& task)` we did not check > for duplicated tasks, so they could be added more than once. > > A simple check has now been added (there is the question of whether the > `operator ==` on `Task` is too strict, so as > never to cause a match). > > This fixes a TODO I came across as part of the work on MESOS-2633 (no Jira > tracking this issue) > > > Diffs > ----- > > src/master/framework.cpp PRE-CREATION > > Diff: https://reviews.apache.org/r/33490/diff/ > > > Testing > ------- > > make check > > > Thanks, > > Marco Massenzio > >
