Automated Evolution of Feature Logging Statement Levels Using Git Histories and Degree of Interest

Introduction Motivation Example Approach Evaluation Conclusion
Automated Evolution of Feature Logging
Statement Levels Using Git Histories and Degree
of Interest
Work In Progress
Yiming Tang1
Allan Spektor2
Raﬃ Khatchadourian2,1
Mehdi
Bagherzadeh3
1
City University of New York (CUNY) Graduate Center, USA
2
City University of New York (CUNY) Hunter College, USA
3
Oakland University, USA
Computer Science, University of Bristol
July 14, 2020
Yiming Tang, Allan Spektor, Raﬃ Khatchadourian, Mehdi Bagherzadeh Automated Evolution of Feature Logging Statement Levels 1 / 43

Introduction Motivation Example Approach Evaluation Conclusion Logging Issues Background
Logging in Modern Software in the Big Data Era
Logging is pervasive in the modern software.
Big data systems deal with high-volumes of transactions.
Source code is tangled with scattered logging statements capturing
important event information.
Essential for reporting security and privacy breaches.

Feature Logging Statements
Modern software is also feature-heavy, implementing hundreds of
features.
Logging statements—although more informational—also capture
important aspects of feature implementations.
Useful for validating feature implementations and diagnosing
unintended interactions with other features.

Logging Issues
Source: Stuart Pilbrow / CC BY-SA
(https://creativecommons.org/licenses/by-sa/2.0)
Too much logging causes
information overload.
Makes postmortem analysis
diﬃcult.
Understanding system behavior
in production and diagnosing
problems can be challenging.
Also challenging during
development as logs pertaining
to auxiliary features are tangled
with those under current
development.

Logging Frameworks & Libraries I
To help alleviate these problems, many programming languages are
accompanied by logging frameworks or libraries.
Allow developers to issue logging statements that consist of a
number of parts dictating how the log should be emitted, if at all.
Logging Statement Components
1 A log object.
2 A log object run time level.
3 A log method that is invoked on the log object.
4 A method parameter representing a priority level.
5 A log message that is emitted iﬀ the log level ≥ the run time level.

Logging Frameworks & Libraries II
Logging Message Components
Includes a (typically) dynamically constructed string consisting of:
Static text.
Dynamic contexts (contents of one of more variables).
Example
logger.log(Level.FINER, "Health is: " +
DiagnosisMessages.systemHealthStatus());
Outputs system health information iﬀ the run time level of logger ≤
Level.FINER.
Log levels limit the kinds of log information emitted either for particular
environments (e.g., development, deployment) or other factors.

Feature Logging Statement Level Evolution I
As software evolves, logging statements levels correlated with
surrounding feature implementations may also need to be modiﬁed.
Such feature logging statements may serve as algorithm checkpoints,
where:
Critical variable values are outputted for validation.
Progress is ensured.
Ideally, levels of feature logs would evolve with the system as it is
developed.
Higher log levels (e.g., INFO) being assigned to logs corresponding to
features with more current stakeholder interest.
Lower log levels for those with less interest (e.g., FINEST).

Feature Logging Statement Level Evolution II
Developers tend not to (manually) change log levels [H. Li et al.,
2017].
Feature log levels can become stale over time.
Irrelevant (production) logs accumulate.
Information overload increases.
Important feature logs tangle with those not currently being
developed.
Manually maintaining this correlation can be tedious and error-prone
as logging statements are highly scattered [Zeng et al., 2019].
Developers may also not utilize the full spectrum of logging levels
available.

Related Work
Source: Jonathan Joseph Bondhus / CC BY-SA
(https://creativecommons.org/licenses/by-sa/3.0)
Existing approaches [Chen and
Jiang, 2017; Hassani et al.,
2018; He et al., 2018; Kabinna
et al., 2018; H. Li et al., 2017]
are inclined to focus on either
new logging statements or log
messages.
Logger hierarchies [Apache
Software Foundation, 2020;
Oracle, 2018] may be but still
require manual maintenance.

Introduction Motivation Example Approach Evaluation Conclusion Version 1 Version 2 Version 3 Final Version
Wombat Class I
1 public class Wombat {
2 private static final Logger logger = // A logger that only logs ≥ FINE ...
3 private int temp;
4 private int oldTemp;
Logger declared on line 2.
Levels include, in ascending order, FINEST, FINER, FINE, INFO,
WARNING, and SEVERE.
Assume only logs with levels ≥ FINE are emitted.
Wombats have a current and previous temperature.

Wombat Class II
1 public class Wombat {
2 private static final Logger logger = // A logger that only logs ≥ FINE ...
3 private int temp;
4 private int oldTemp;
5
6 public void setTemp(int val) {
7 this.oldTemp = temp;
8 this.temp = val;
9 logger.log(Level.FINER, "Temperature set to: " + this.temp);
10 logger.finer("The old temperature was: " + this.oldTemp);
11 } // ...
Temperature mutator of line 6.
Logging statements on lines 9–10.
Various ways to log.
Both have no eﬀect due to run-time level.

Wombat Client
12 public static void main(String[] args) throws Exception {
13 Wombat w = new Wombat();
14 Scanner scanner = new Scanner(System.in);
15
16 System.out.println("Enter a temperature:");
17 int input = scanner.nextInt();
18 w.setTemp(input);
19
20 try { // send to file.
21 logger.fine("Writing to file.");
22 Files.writeString(new File("output.txt").toPath(), w.toString(),
23 StandardOpenOption.WRITE);
24 } catch (IOException e) { // Fatal error.
25 logger.severe("Couldn't open file for writing.");
26 throw e;
27 }
28 }
29 }
Writing Wombat to ﬁle on lines 22–23.
Feature logging statement at 21 emitted (≥ run-time level).
Error log at line 25.

Evolution I
Rejecting Invalid Temperatures
We now add code to reject setting negative temperatures:
1 @@ -23,11 +23,15 @@ public void setTemp(int val) {
2 + if (val > 0) {
4 this.temp = val;
5 logger.log(Level.FINER, "Temperature set to: " + this.temp + ".");
7 + } else {
8 + throw new IllegalArgumentException("Invalid temperature: " + val);
9 + }
10 } // ...

Evolution II
Rejecting Invalid Temperatures
This induces a client change:
1 @@ -38,7 +42,17 @@ public static void main(String[] args) throws Exception
2 int input = scanner.nextInt();
3 + while (true) {
4 + try {
5 w.setTemp(input);
6 + break; // succeeded.
7 + } catch (IllegalArgumentException e) {
8 + // Not a fatal error. Log the exception and retry.
9 + logger.log(Level.INFO, "User entered invalid input: " + input, e);
10 + System.out.println("Invalid temperature. Please retry.");
11 + }
12 + }
A log is issued when the thrown exception is caught on line 9.
Documents the retry.
Because the error is non-fatal, the INFO level is used.

More Evolution
Warning About Drastic Temperature Changes
An ensuing commit logs drastic temperature changes:
1 @@ -30,6 +30,9 @@ public void setTemp(int val) {
2 } else {
3 throw new IllegalArgumentException("Invalid temperature: " + val);
4 }
5 +
6 + if (((double) (this.temp - this.oldTemp)) / this.oldTemp > 0.05)
7 + logger.warning("Temperature has risen above 5%.");
8 } // ...
In setTemp(), a warning is logged on line 7 if the temperature has
increased above 5%.

Log Level Rejuvenation I
Abbreviated Final Example
7 if (val > 0) {
9 this.temp = val;
12 } else {
14 }
15
16 if (((double) (this.temp - this.oldTemp)) / this.oldTemp > 0.05)
17 logger.warning("Temperature has risen above 5%.");
18 } // ...
Levels at lines 10–11 have increased from FINER to FINE.
Due to recent changes made to nearby code.
Features implemented at this part of the code, e.g., temperature
management, is of a higher “interest” to developers.
May help developers debug the new feature code.
Will now emit due to the logger’s run-time log level of FINE.

Log Level Rejuvenation II
19 public static void main(String[] args) throws Exception { // ...
20 } catch (IllegalArgumentException e) {
21 // Not a fatal error. Log the exception and retry.
22 logger.log(Level.INFO, "User entered invalid input: " + input, e);
23 }
24
26 logger.finest("Writing to file.");
27 Files.writeString(new File("output.txt").toPath(), w.toString(),
28 StandardOpenOption.WRITE);
31 throw e;
32 }
33 }
Level at line 26 decreased from FINE to FINEST.
Not under active development.
Log is now suppressed.
Level at line 30 did not have its level lowered.
Non-fatal level at line 22 also not lowered despite recent non-local
edits.

Introduction Motivation Example Approach Evaluation Conclusion Overview Level Extraction DOI Manipulation Mismatches Heuristics
Approach
Automatically assist developers in evolving feature logging statement
levels.
Mine Git repositories to discover the “interestingness” of code
surrounding feature logging statements.
Adapt the degree of interest (DOI) model of Mylyn [Kersten and
Murphy, 2005].

Overview
Figure: Logging Level rejuvenation approach overview.

Feature Logging Statement Level Extraction
Input is a set of projects.
Logging statements extracted in step 1 using ASTs.
Levels extracted in step 2 using two cases:
Convenience APIs Simply use method name.
Standard APIs Extract parameter.

What is Mylyn?
Standard Eclipse Integrated Development
Environment (IDE) plug-in.
Focuses graphical components of the IDE.
Only “interesting” artifacts related to the
currently active task are revealed [Kersten
and Murphy, 2006].
The more interaction with an artifact
(e.g., ﬁle), the more prominent it appears
in the IDE.
Less recently used artifacts appear less
prominently.

Mylyn Adaptation
Programmatically manipulate a DOI model using Git code changes.
Transform source code to “rejuvenate” feature logging statement
levels.
Pull those related to features whose implementation is worked on
more and more recently to the forefront.
Push those related to features whose implementations are worked on
less and less recently to the background.
Goals
Reduce information overload.
Support system evolution.
Automatically bring more relevant features to developers’ attention
and vice-versa.
Security
There’s also security implications, speciﬁcally regarding side-channel
attacks, which we will touch on later.

Repository Mining
We adapt the Mylyn context to ascertain the interest levels of code
surrounding logging statements.
Conceptually expand the context to include interests from all
developers by mining Git repository log information (step 3).

Converting Code Changes to Interaction Events
Mylyn “interaction events” dictate how the DOI model changes.
Based on developer interactions within the IDE.
Convert “edit” events in Git to interaction events in Mylyn (step 4).
Mylyn processes these as if they were from the IDE (step 5).

Rename Refactorings & Copying
Program elements (e.g.,
methods) changed in Git may
no longer exist in current
project version.
Must process rename
refactorings.
Maintain a data structure that
associates rename relationships
between program elements,
e.g., method signatures.
Use lightweight refactoring
approximations.
Use copy detection features of
Git at the ﬁle level.
New copy “inherits” old DOI
values.

DOI-Feature Logging Level Association
DOI values (real non-negative) from ﬁnal model are partitioned.
Partitions can be guided via heuristics (e.g., do not consider
WARNING, SEVERE).
DOI ranges are associated with logging levels (step 6).
Reduced DOI decay rate so that even partitions worked well.

Identifying DOI-Feature Logging Level Mismatches
Potential mismatches are discovered using the partitions (step 7).
Compare partitions with current feature logging statement levels.
If a mismatch is found, the statement is marked for potential
transformation.

Classifying Feature Logging Statements
Logging levels are often used to diﬀerentiate various logging
“categories” (e.g., severe errors, security breaches).
Need to distinguish between these and feature logs.
Derive a set of heuristics based on ﬁrst-hand developer interactions.
Also distinguish between less-critical debugging logs (e.g., tracing)
using a keyword-based approach.
Goals
Focus on only manipulating logging statements tied to features to better
align them with developers’ current interests.

Feature Logging Statement Heuristics
1 Treat particular levels as log categories (e.g., WARNING, SEVERE).
2 Never lower levels appearing within catch blocks.
3 Never lower levels immediately following branches (e.g., if, else).
4 Never change levels immediately following branches whose condition
contains a log level.
Circumvents logging API “wrapping.”
5 Never lower levels having particular keywords in their log messages.
Keywords include “fail,” “disabl,” “error,” and “exception.”
6 Never raise levels without particular keywords in their log messages.
Keywords include “stop,” “shut,” “kill,” “dead,” and “not alive.”
Only applies for target levels WARNING or SEVERE.
Does apply when Item 1 is enabled.
7 Only consistently transform levels appearing in overriding methods.
Preserves “behavioral subtyping” relationships.
8 Only transform levels up to a transformation distance threshold.
Limits the extent of modiﬁcations.

Log Level Rejuvenation Revisited I
7 if (val > 0) {
9 this.temp = val;
12 } else {
14 }
15
16 if (((double) (this.temp - this.oldTemp)) / this.oldTemp > 0.05)
17 logger.warning("Temperature has risen above 5%.");
18 } // ...
Levels at lines 10–11 have increased from FINER to FINE.
Passes Item 6 as target level is not WARNING or SEVERE.
Code at line 17 was recently added.
Nevertheless, the level would not be lowered due to Item 3.

Log Level Rejuvenation Revisited II
19 public static void main(String[] args) throws Exception { // ...
20 } catch (IllegalArgumentException e) { // ...
21 logger.log(Level.INFO, "User entered invalid input: " + input, e);
22 }
24 logger.finest("Writing to file.");
25 Files.writeString(new File("output.txt").toPath(), w.toString(), // ...
28 throw e;
29 }
30 }
Level at line 24 decreased from FINE to FINEST.
Not in a catch block (Item 2).
No “anti-lowering” keywords (Item 5).
Level at line 27 did not have its level lowered.
In a catch block (Item 2).
Contains “anti-lowering” keywords (Item 5).
Non-fatal level at line 21 also not lowered despite non-local edits.
Similar reasons as above.

Implementation
Implemented as an open-source plug-in to the Eclipse IDE.
May also be used with popular build systems via plug-ins.
Supports two popular logging frameworks, SLF4J and JUL.
Integrates with JGit and Mylyn.
Available at https://git.io/fjlTY.

Research Questions
1 How applicable is our tool to
and how does it behave with
real-world open source
software?
2 How does the results of our
tool compare with log level
transformations made by
developers?
3 Do developers ﬁnd the results
acceptable? What is the impact
of our tool?

In-Progress Evaluation I
Conﬁguration
18 Java projects.
˜3 million lines of code.
˜4K logging statements.
General Findings
Fully-automated analysis cost is viable.
Average running time of 10.66 secs per candidate logging statement.
0.89 secs per thousand lines of code changed.
Developers do not actively think about how their logging statement
levels evolve with their software.
Proposed approach is promising in assisting developers to evolve
feature log levels.

In-Progress Evaluation II
Question 1
subject HEAD KLOC Kcmts δKLOC fw logs fails trans catch ifs conds keyl keyr inh distance σbefore σafter low raise t (m)
bc-java a66e904 701.57 6.00 1,213.28 1 56 4 11 5 13 6 16 0 0 2.64 (1.30) 1.49 2.01 11 0 62.78
blueocean*
c3bfac5 49.32 4.06 137.85 2 109 0 13 11 6 5 57 9 0 1.54 (0.63) 1.65 1.74 11 2 2.93
californium 5b026ab 79.35 1.00 143.53 1 986 0 141 23 123 95 317 176 2 1.52 (0.73) N/A N/A 118 22 7.51
CoreNLP d7356db 535.07 6.00 43,686.03 2 358 0 146 0 87 21 55 0 0 3.10 (1.43) 1.84 2.16 146 0 444.99
deviation*
88751d6 6.52 0.08 24.81 1 91 0 11 1 7 8 48 3 0 2.64 (1.23) 1.69 2.07 11 0 0.06
errorprone 2118ba3 164.65 3.99 517.18 1 12 0 1 1 0 1 9 0 0 2.00 (0.00) 1.61 1.86 1 0 17.36
guava 71de406 393.69 1.00 296.52 1 36 0 0 0 0 0 33 0 0 0.00 (N/A) 1.52 1.52 0 0 29.63
hollow ﬀ635ee 68.60 0.90 158.73 1 31 0 6 0 3 0 22 0 0 3.50 (1.12) 1.02 1.98 5 1 2.86
IRCT d67f539 42.29 0.89 193.69 1 13 0 6 0 0 0 2 1 0 2.00 (1.41) 1.22 1.51 6 0 2.07
JacpFX 14c2a4c 24.06 0.37 121.41 1 21 0 2 4 0 7 8 0 0 2.50 (1.50) 1.47 1.69 2 0 0.77
jdp*
515b7e7 35.86 1.00 99.99 2 799 0 180 17 15 4 84 399 0 1.70 (0.63) 0.00 1.79 139 41 3.18
jenkins 4f0436a 160.60 1.00 25.28 1 503 22 60 29 52 54 244 22 0 2.17 (1.25) 1.73 1.84 58 2 3.81
jsilhouette 8de4e64 2.35 0.03 5.52 1 22 0 0 0 8 0 14 0 0 0.00 (N/A) 0.00 0.00 0 0 0.04
junit5 3969585 73.59 5.98 380.61 1 9 2 4 0 0 0 2 0 0 3.00 (1.00) 0.00 1.67 4 0 75.25
OpenGrok 0f3b14d 71.65 4.93 377.09 1 592 3 61 44 49 41 353 13 0 2.70 (1.47) 1.81 2.07 53 8 15.20
selenium a49fb60 93.61 1.00 75.97 1 94 0 28 5 6 0 48 4 0 2.96 (0.94) 1.00 1.75 27 1 1.45
SpotBugs ecc7994 187.78 1.00 94.11 2 96 0 44 2 15 6 26 0 0 1.57 (0.96) 1.74 2.30 44 0 26.59
WALA b73a0b2 202.45 1.00 235.50 2 145 0 39 1 38 0 22 16 1 1.41 (0.54) 0.94 0.94 38 1 9.20
Total 2,893.01 40.22 47,787.09 1.28 3,973 31 753 143 422 248 1,360 643 3 2.13 (1.23) 1.75 2.05 674 78 705.68
*
blueocean is blueocean-plugin, deviation is deviation-upload, and jdp is java-design-patterns.
Successfully analyzes 99.26% of candidate logging statements.
Literal parameter extraction.
No data-ﬂow analysis.
Increases log level distributions by an average of 17.14%.

In-Progress Evaluation III
Question 2
subject cHEAD tHEAD Kcmts TP FP FN distR direct
blueocean*
de8b8ca de8b8ca 1.00 0 2 0 N/A N/A
guava 8385600 638fcb8 1.00 3 0 0 33.33 3
IRCT-API aa0f039 86d2c49 0.13 1 10 0 83.33 0
jsilhouette be37202 be37202 0.03 0 0 0 N/A N/A
junit5 c7c5796 2fab23a 0.47 4 15 4 25.00 4
SpotBugs 190e1e1 35804ee 1.00 14 29 2 24.49 13
WALA 7f68e76 3317c1c 1.00 1 0 0 50.00 0
Total 15.37 23 56 6 29.40 20
*
blueocean is blueocean-plugin.
Extracted manual edits to log levels from Git histories.
Identiﬁes logs that were manually modiﬁed by developers with a:
79.31% recall.
86.96% level direction match success rate.
Precision of 29.11%.
May indicate that our tool can suggest further transformations not
originally considered by developers.

In-Progress Evaluation IV
Question 3
A pull request study successfully integrated into 2 large and popular
open-source projects.
9 projects have pending requests.
5 projects have rejected requests.
Accepted PRs
Projects accepting requests include Jenkins, a popular continuous
integration (CI) engine, having ˜15K stars and ˜6.1K forks on
GitHub, and selenium, a prominent web application testing and
automation tool, having ˜17K stars and ˜5.6K forks.
Accepted our pull requests at rates comparable to previous
work [S. Li et al., 2018].

In-Progress Evaluation V
Rejected PR Feedback
Feedback from rejected pull requests includes thoughts on whether
or not our approach is applicable to very mature and largely stable
projects that are in “maintenance mode” [Baker, 2019b; Stewart,
2019].
Developers consistently changing diﬀerent parts of the system due to
bug reports.
A question [Baker, 2019a] was also raised regarding the approach’s
applicability to library vs. application code.
Parts of a library that are important to library developers may not
match the interest level of application developers using the library.

Summary
Feature logging statements document important values and track
progress of feature implementations.
As interest of features evolve, feature logging levels may also require
modiﬁcation to combat information overload.
Our in-progress approach discovers and rectiﬁes mismatches between
feature interest levels and logging levels.
Results show that the technique is promising in alleviating the
burden of manually evolving logging levels.

Ongoing Work I
More developer feedback (surveys).
Bug study.
Security implications.
Expand keyword set to involve security and privacy terms.
Explore implications for side-channel attacks.

Ongoing Work II
Side-channel Attacks
Log messages may leak sensitive information about the system to
attackers.
However, most logs reside on servers not accessible by attackers.
Nevertheless, printing logs takes server time.
Attackers can deduce properties of the system based on this time.
This is called a side-channel attack.
Can infer sensitive information related to authentication and
authorization.
For example, log a successful/unsuccessful authentication request.
Our approach may be able to proactively prevent logging-based
side-channel attacks.
Logging is pervasive, especially in server applications.
May be used to suppress feature logs on production servers.
Prevent timing information from leaking to attackers.

For Further Reading I
Apache Software Foundation (2020). Log4j. Log4j 2 Architecture. url:
http://logging.apache.org/log4j/2.x/manual/architecture.html#Logger_Hierarchy (visited on 06/12/2020).
Baker, David P. (Nov. 20, 2019a). Rejuvenate log levels by anonymous • Pull Request #3713 • google/guava. Following this URL may
reveal author identity. Google. url: http://git.io/Jfdae (visited on 06/17/2020).
Baker, David P. (Apr. 5, 2019b). Rejuvenate logging statement levels by anonymous • Pull Request #3435 • google/guava. Following
this URL may reveal author identity. Google. url: http://git.io/Jfdal (visited on 06/17/2020).
Chen, Boyuan and Zhen Ming (Jack) Jiang (2017). “Characterizing and Detecting Anti-Patterns in the Logging Code”. In: International
Conference on Software Engineering. ICSE ’17. Buenos Aires, Argentina: IEEE Press, pp. 71–81. isbn: 9781538638682. doi:
10.1109/ICSE.2017.15.
Eclipse Foundation, Inc. (2020). JGit. url: http://eclip.se/gF (visited on 03/02/2020).
Hassani, Mehran et al. (Mar. 2018). “Studying and detecting log-related issues”. In: Empirical Software Engineering. issn: 1573-7616.
doi: 10.1007/s10664-018-9603-z. url: https://doi.org/10.1007/s10664-018-9603-z.
He, Pinjia et al. (2018). “Characterizing the Natural Language Descriptions in Software Logging Statements”. In: International Conference
on Automated Software Engineering. ASE 2018. Montpellier, France: ACM, pp. 178–189. isbn: 9781450359375. doi:
10.1145/3238147.3238193.
Kabinna, Suhas et al. (Feb. 2018). “Examining the Stability of Logging Statements”. In: Empirical Softw. Engg. 23.1, pp. 290–333. issn:
1382-3256. doi: 10.1007/s10664-017-9518-0.
Kersten, Mik and Gail C. Murphy (2005). “Mylar: a degree-of-interest model for IDEs”. In: International Conference on Aspect-Oriented
Software Development. Chicago, Illinois: ACM, pp. 159–168. isbn: 1-59593-042-6. doi: 10.1145/1052898.1052912.

For Further Reading II
Kersten, Mik and Gail C. Murphy (2006). “Using Task Context to Improve Programmer Productivity”. In: ACM Symposium on the
Foundations of Software Engineering. SIGSOFT ’06/FSE-14. Portland, Oregon, USA: ACM, pp. 1–11. isbn: 1-59593-468-5. doi:
10.1145/1181775.1181777.
Li, Heng, Weiyi Shang, and Ahmed E. Hassan (Aug. 2017). “Which Log Level Should Developers Choose for a New Logging Statement?”
In: Empirical Softw. Engg. 22.4, pp. 1684–1716. issn: 1382-3256. doi: 10.1007/s10664-016-9456-2.
Li, Shanshan et al. (2018). “Logtracker: Learning Log Revision Behaviors Proactively from Software Evolution History”. In: International
Conference on Program Comprehension. ICPC ’18. Gothenburg, Sweden: ACM, pp. 178–188. isbn: 978-1-4503-5714-2. doi:
10.1145/3196321.3196328.
Oracle (2018). Logger (Java SE 10 & JDK 10). url:
http://docs.oracle.com/javase/10/docs/api/java/util/logging/Logger.html (visited on 02/29/2020).
Stewart, Simon (May 7, 2019). Rejuvenate log levels by anonymous • Pull Request #7170 • SeleniumHQ/selenium. Following this URL
may reveal author identity. Selenium. url: http://git.io/JfdaA (visited on 06/17/2020).
Zeng, Yi et al. (Feb. 2019). “Studying the characteristics of logging practices in mobile apps: a case study on F-Droid”. In: Empirical
Softw. Engg. 24, pp. 3394–3438. issn: 1573-7616. doi: 10.1007/s10664-019-09687-9.

Automated Evolution of Feature Logging Statement Levels Using Git Histories and Degree of Interest

More Related Content

What's hot (20)

Similar to Automated Evolution of Feature Logging Statement Levels Using Git Histories and Degree of Interest (20)

More from Raffi Khatchadourian (20)

Recently uploaded (20)

Automated Evolution of Feature Logging Statement Levels Using Git Histories and Degree of Interest