Review discussion and conclusion

src/conclusions-and-further-work.tex

@@ -1,12 +1,15 @@
 \chapter{Conclusions and Further Work}
 
 \section{Conclusions}
+
+\lm{Comment on structure: here, you can eliminate the {\textbackslash}section tag and begin with something along the lines of: ``This thesis presents the following work:'' [...]. You can still leave ``Further work'' in a separate section though.}
+
 We succeeded in porting the IxOS infrastructure on ARM boards. We separated the
 relevant components for our porting (i.e., InterfaceManager and IxStack) from
-IxOS so that they can be run on every ARM-based Linux distribution. At the
+IxOS so that they can be run on every~\lm{on any?} ARM-based Linux distribution. At the
 moment of writing the project is in the proof-of-concept stage. If there is
 interest for continuing the project or integrating it in other projects inside
-the company, we provided the necessary environment for deploying it.
+the company, we provided the necessary environment for deploying it.~\lm{Not sure that the last two sentences are needed at all.}
 
 We have extracted the porting costs for porting IxOS infrastructure on ARM
 boards. Thus we understood what the weaknesses and the strengths of our project
@@ -15,14 +18,14 @@ proved itself to be an important factor during the process of porting. Because
 of this reason we had to spend additional time on testing the system and
 understanding its components. This time might have been better allocated on
 solving problems and inconsistencies. A strength of our project was the fact
-that the program for porting had a high degree of portability. This helped us to
+that the program for porting~\lm{the ported program?} had a high degree of portability. This helped us to
 shrink the volume of inconsistencies between the source environment and the
 target environment.
 
-We succeeded in creating a better model for software porting starting from the
+We succeeded in creating a better~\lm{In what sense is it ``better''? is it more accurate? is it more comprehensive? try to be more specific.} model for software porting starting from the
 model presented in~\cite{hakuta,tanaka} and from our project specific needs. We
 contributed to this model by making it more generic and allowing other software
-porting projects to easily map their needs on this model.
+porting projects to easily map their needs on this model.~\lm{Ah, I see. I think you should just say this, and also briefly say why we needed to extend their model.}
 
 Finally, we have provided a discussion on the limitations of the model we
 created and provided a comparison between our porting results and the results
@@ -32,18 +35,18 @@ basis for our generic porting model.
 \section{Further Work}
 
 We plan to test the performance of the system so that we can achieve the other
-goal we proposed in the beginning of this work (i.e., explore Ixia testing
+goal we proposed in the beginning of this work~\lm{Rather, I would formulate this as such: we want to explore other aspects of our port to ARM.} (i.e., explore Ixia testing
 infrastructure on other architectures so that we can achieve a better
 performance of the system). To achieve this goal we will compare our solution in
 the target environment with the same solution in the source environment. We
 expect to see better results in the new environment for some network testing
 suites than in the old environment. Furthermore, we plan to compare our solution
-with other open-source network testing tools.
+with other open-source network testing tools.~\lm{Ixia is already better than open-source network testing tools, so... I don't know.}
 
 To complete the analysis of the factors that affected the porting costs we plan
 to analyze the characteristics of the program to be ported. We want to analyze
 the program size and contents and the content of the changes needed for porting.
-By doing this we hope to find a direct correspondence between the program to be
+By doing this we hope~\lm{rather, we aim?} to find a direct correspondence between the program to be
 ported and specific porting subtasks (e.g., \textit{Solving inconsistencies
 between source and target environment}).
 
@@ -51,3 +54,5 @@ Finally, we want to analyze the porting improvements guidelines presented
 in~\cite{hakuta} and map them on our porting process. However, we do not plan to
 restart the porting process while mapping these guidelines, instead we want to
 have a discussion and draw conclusions based on them.
+
+\lm{I think there is a more general question to be answered here for future work (and it might have been largely solved by the IxOS team, I don't know): can this protocol/control plane infrastructure be provided as a drop-in component for any Linux-based system? regardless of the target architecture, supposing a C++ compiler exists for it; and regardless of the specifics of the target Linux environment, supposing it's standard Linux. If this is possible, then it's a big win for Ixia, since they can deploy the control plane tester anywhere (cloud, commodity boards, other systems that we haven't thought of yet). Not sure whether to mention this explicitly here, but it is certainly worth mentioning that we want the testing infrastructure to be portable to as many environments (OS, compiler, architecture) as possible.}

src/discussions.tex

@@ -1,5 +1,9 @@
 \chapter{Discussions on Porting Costs} \label{sec:discussion}
 
+\lm{You need to briefly summarize the chapter here, even if you don't say much.}
+
+\lm{This chapter is structured a bit weirdly: you have a chapter named ``Discussions on Porting Costs'', whose first section is ``Discussions'' (almost the same name as the chapter) and the second section is ``General difficulties''. I'm not saying this is necessarily wrong, it's just not very clear why it's structured this way.}
+
 % What I want to say in this section:
 %   - I want to reflect on imporving the porting process we did. Tanaka proposes
 %   the following seven ways of raising porting efficiency:
@@ -39,7 +43,7 @@ comparison between our results and the results of Tanaka et al.
 \subsection{Limitations of the porting model}
 
 Let us start by discussing the limitations of the porting model we proposed in
-section~\ref{sec:background}. The model assumes that the tasks are executed in
+section~\ref{sec:background}.~\lm{You can leave out this first sentence and just begin with: ``The model in sec:background assumes that [...]''.} The model assumes that the tasks are executed in
 sequential order, which is not true. The tasks are rather executed in a
 non-linear fashion. For example while building for the target environment,
 installing the binaries in this environment and testing the ported application,
@@ -98,6 +102,8 @@ with the provided tools and systems. Furthermore, to have a more accurate
 conversion there must be time considerents: how much time did we spent on this
 bullet? and how do we divide this time between porting tasks?
 
+\lm{If I understand correctly, the problem here is one of taxonomy: a given task could fall into more than one category, or rather, the time allocated to that task could be broken between multiple categories. I'm wondering, then: do the ``porting task categories'' themselves represent the porting process? Or is there some better way to break down porting processes (in general)?}
+
 \subsection{Dependencies between porting tasks}
 
 The next discussion point focuses on the porting tasks dependency graph. It
@@ -119,7 +125,7 @@ produce, progress tracking must reflect work executed in each subtask and
 discussions are by design focused on trying to understand each part of the
 porting process. That being said, it is hard to imagine how \textit{General
 duties} would not be a substantial part of the porting process. It would be
-interesting too see if a modification in the allocated time for a subtask such
+interesting to see if a modification in the allocated time for a subtask such
 as \textit{Discussions} would reduce or increase the needed time for other
 subtasks, otherwise if other tasks are not affected by this modification, there
 should be no interest in allocating more time for discussing.
@@ -129,9 +135,9 @@ should be no interest in allocating more time for discussing.
 At this moment we discussed the limitations and open problems that appear in the
 model of porting we used. Next, we make a comparison between our results for
 porting costs and the results that appeared in the first paper that presented a
-basis for our porting model~\cite{b1}. The results can be found in Table 6 of
+basis for our porting model~\cite{b1}~\lm{There is a missing reference here.}. The results can be found in Table 6 of
 the paper we referenced. We will compare the subtotals per tasks and discuss the
-reasons of the differences between the two . In terms of \textit{Advance
+reasons of the differences between the two. In terms of \textit{Advance
 preparations} we spend a total of 14.35\% of our total time while Tanaka et al.
 spend 33.4\%. There are two major reasons for reduced time in our case. First,
 we were interested in delivering builds for the target environment as fast as
@@ -162,7 +168,7 @@ a larger ecosystem into a target environment, their project was focused on
 porting a whole application from one environment to another.
 
 For \textit{Testing} we assume that they spent $\textit{Linked test on target} /
-2 + \textit{Workstation testing} = 10.5 + 11.4 = 21.9\%$. We dived the linked
+2 + \textit{Workstation testing} = 10.5 + 11.4 = 21.9\%$. We dived~\lm{divided?} the linked
 test on target because we assumed that half of this time was allocated to
 development and half of it was allocated to testing. Their time for
 \textit{General duties} is of 27.4\%. These two times are very similar with our
@@ -172,7 +178,7 @@ evaluating the costs in advance, special attention must be payed to these tasks.
 
 \section{General difficulties}
 
-After describing the impediments we faced during our porting we decided
+After describing the impediments we faced during our porting~\lm{Not sure this applies anymore. I think you should make this section self-contained, without references such as this.} we decided
 to understand them and create a list with general difficulties along with a
 short description of each difficulty. This list helps the reader understand what
 were the major technical impediments that affected the course of our porting.
@@ -189,16 +195,16 @@ This difficulty corresponds to the degree of which the application is
 portable~\cite{mooney2004developing}. If the degree of portability is too low
 (this depends entirely on the application) then the developer will be faced with
 many inconsistencies between the source and target environments that will be
-reflected in the cost of porting (i.e., man-hours).
+reflected in the cost of porting (i.e., man-hours).~\lm{Don't these inconsistencies also depend on the environments themselves, though?}
 
 \subsection{Use of tools}
 Using inadequate development and testing tools introduces additional
 overhead in the porting process. This happens when the used tools are either
-outdated or too hard to use for the purpose of the process.
+outdated or too hard to use~\lm{I'm still not bought on the ``outdated'' aspect; developers shouldn't suffer just because a maintainer decides to break compatibility with an older version of a tool.} for the purpose of the process.
 
 \subsection{Understanding the system}
 Software complexity is a multi-dimensional problem, it includes: structural,
-computational, logical, conceptual and textual complexity.  ~\cite{ejiogu} There
+computational, logical, conceptual and textual complexity~\cite{ejiogu}. There
 is no easy way to understand the system, so the developer will be faced with the
 task of understanding the architecture diagrams, huge code base, written
 documents and tutorials either when the porting starts or during the porting
@@ -210,4 +216,4 @@ that can not be estimated beforehand. They include unknown parts of the software
 that may cause problems when ported or assumptions about the environment made by
 the system that will not work in the target environment. The only time they
 are clearly reflected in the porting costs is at the end of the project where
-a retrospective is led.
+a retrospective is led.~\lm{I know I commented at least twice in the past on this paragraph and I'm still unconvinced about it. One needs to look deeper into what this ``unexpected'' means, or rather, what causes it. To my eye, something is always unexpected in the context of partial information, so ``Unexpected difficulties'' is not disjoint from ``Understanding the system''. You have to ask yourself: had you known more things beforehand (e.g. architectural details about IxOS, or RPi delivery date), would the unexpected difficulties still be unexpected? If not, then there's really nothing ``unexpected'' about them, they were just caused by lack of familiarity with the system.}