cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject Re: Feedback of my Phd work in CXF project
Date Thu, 10 Dec 2015 13:50:13 GMT
Thanks for the explanations.

I think the idea of giving people some hint that classes are connected 
(according to your rules) makes a lot of sense.
Like you said this can help newcomers to navigate around the code. For 
this purpose an IDE plugin makes sense.

I am not sure about the review part. As a reviewer you will always see 
the changeset and you know you got to review
all changes. Your tool could report a file that was expected to be also 
changed but was not. As this would probably mean that
something was forgotten to change a test should catch that.

Btw. JMSConduit and JMSOldConfigHolder are connected through 
JMSConfiguration. So there is no direct connection but they are also not 
far from each other structurally.
I am not sure if your system takes the connections into account but it 
would surely make sense to do so. For example if you find out that files 
are often changed together you could graphically show how they are 
connected structurally. This together with the statistical predictions 
could be some real help.

Christian


On 10.12.2015 14:03, igorwiese wrote:
> Hi Christian. Thanks for answer.
>
> Your first question is interesting. Usually this is the natural reason why
> we changed two files. We are always expecting some kind of structural
> connection between classes (eg implements, extends, instantiation, etc.).
> However we found many cases (issues) with commits where files are not
> "structurally connected".
>
> For example: JMSConduit.java and JMSOldConfigHolder.java are not
> structurally connected, despite being in the same package. We found that 15
> commits they changed together, but in other 18 commits only JMSConduit
> changed without the presence of JMSOldConfigHolder.java. If you consider a
> "natural" reason you can make 18 mistakes, or at least, you will lost your
> time inspecting JMSOldConfigHolder.java 18 times.
>
> Our assumption is that "this real reason" can be, in fact, "many different
> reason". Because of this, using only structural dependencies can be not good
> in all situations, and can misleading the developers.
>
> A simple scenario:
> - You are working in a issue, and committed the file JMSConduit.java. What
> other files you could change to complete this issue?
> - Based on the past issues/commits when JMSConduit was changed, we collect
> contextual information that describe the situations when JMSConduit changed
> or not with JMSOldConfigHolder.java, and then we can recommend you to
> inspect this file to change or not.
>
> We collect data from all possible combinations envolving JMSConduit and
> other files of the system.
> - What we are reporting is that in 86% of the cases that we tested this
> combinations (you can check all of combination in the website), we correctly
> predicted when both files will change together in an specific issue/commit.
>
> About the practical aspects (what can be done). A researcher from our
> research group interviewed newcomers and they said that it is difficult to
> find right files to change in their first contributions. In this case, as a
> newcomer is difficult to complete the issues/pull requests because they
> don't understand much the code or the architecture. Debugging tasks are also
> not trivial in all projects. In such cases newcomers could use our approach
> (we are building a tool) to receive recommendations while performing the
> task.
>
> In the other hand, let's suppose that you are a core member and you are
> reviewing the Pull Request, we could give you a list of files to check, if
> all of them are in the set of commits made to the issue/pull request. Of
> course we are not claiming that you need to stop the test cases or the
> continuous integration. It is another tool to help during the code review
> tasks.
>
> We are working in a prototype.. we don't know yeat if we will build a
> "monitor" as a web service that you could integrate inside the Issue
> tracker, or as a plugin to some IDE.
>
> So the main ideia here is "avoid" the incomplete change that could causes a
> new bug appearing, or avoid waisting time to inspect files/debugging system
> to find files to change in a issue.
>
>
>
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/Feedback-of-my-Phd-work-in-CXF-project-tp5763765p5763780.html
> Sent from the cxf-dev mailing list archive at Nabble.com.


-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com


Mime
View raw message