From ee2ad6292e7a6c250361ff6ef06027d1b3992fd5 Mon Sep 17 00:00:00 2001 From: Lucian Popescu Date: Sat, 18 Jun 2022 15:16:14 +0300 Subject: [PATCH] Review discussions --- src/discussions.tex | 43 ++++++++++++++++++++++++------------------- 1 file changed, 24 insertions(+), 19 deletions(-) diff --git a/src/discussions.tex b/src/discussions.tex index 441afe2..a122007 100644 --- a/src/discussions.tex +++ b/src/discussions.tex @@ -1,9 +1,5 @@ \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: @@ -34,7 +30,14 @@ % any porting whatsoever (this discussion is in ../src -> background section if % i remember correctly) -\section{Discussions} +In this chapter we discuss some conclusions of our porting work including the +limitations of the porting model we used and factors for these limitations, +namely the dependency between porting tasks. We also compare our results with +the results of the first paper that published a porting model to understand what +were the differences between our and their results and conclusions. Finally, we +also present general difficulties that we extracted from our porting. + +\section{Conclusions of our porting} In this section we present observations about the porting process and the porting costs, focusing on the limitations of the porting model we used and on a @@ -42,8 +45,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}.~\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 +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, @@ -103,6 +105,7 @@ 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)?} +\lp{I don't know how to answer that question} \subsection{Dependencies between porting tasks} @@ -130,12 +133,12 @@ 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. -\subsection{Comparison between our results and the results of Tanaka et al.} +\section{Comparison between our results and the results of Tanaka et al.} 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}~\lm{There is a missing reference here.}. The results can be found in Table 6 of +basis for our porting model~\cite{tanaka}. 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 preparations} we spend a total of 14.35\% of our total time while Tanaka et al. @@ -168,7 +171,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~\lm{divided?} the linked +2 + \textit{Workstation testing} = 10.5 + 11.4 = 21.9\%$. We 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 @@ -178,10 +181,9 @@ 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~\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. +This section presentes the general impediments we faced during our porting. The +difficulties were extracted from the parcitular technical difficulties we faced +during the porting process. \subsection{Lacking documentation} Lacking written documentation about how the system works means @@ -192,15 +194,18 @@ slower than documentation through written text. \subsection{Inconsistencies between environments} 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).~\lm{Don't these inconsistencies also depend on the environments themselves, though?} +portable~\cite{mooney2004developing} between two given environments. 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). \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~\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. +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.} +\lp{is there something we can do regarding this?} +for the purpose of the process. \subsection{Understanding the system} Software complexity is a multi-dimensional problem, it includes: structural,