Pub Date : 2019-09-01DOI: 10.1109/ICSME.2019.00068
Kazumasa Shimari, T. Ishio, Tetsuya Kanda, Katsuro Inoue
Logging is an important feature for a software system to record its run-time information. Detailed logging allows developers to collect information in situations where they cannot use an interactive debugger, such as continuous integration and web application server cases. However, extensive logging leads to larger execution traces because few instructions could be repeated many times. To record detailed program behavior within limited storage space constraints, we propose Near-Omniscient Debugging, a methodology that records an execution trace using fixed size buffers for each observed instruction. Our tool monitors a Java program's execution and annotates source code with observed values in an HTML format. Developers can easily investigate the execution and share the report on a web server. In case of DaCapo benchmark applications, our tool requires fewer than 1% of the complete execution traces to visualize all runtime values used by 66% of instructions that are executed less than 64 times. Developers also can obtain data dependencies with precision 91.8% and recall 79.0% using this tool.
{"title":"Near-Omniscient Debugging for Java Using Size-Limited Execution Trace","authors":"Kazumasa Shimari, T. Ishio, Tetsuya Kanda, Katsuro Inoue","doi":"10.1109/ICSME.2019.00068","DOIUrl":"https://doi.org/10.1109/ICSME.2019.00068","url":null,"abstract":"Logging is an important feature for a software system to record its run-time information. Detailed logging allows developers to collect information in situations where they cannot use an interactive debugger, such as continuous integration and web application server cases. However, extensive logging leads to larger execution traces because few instructions could be repeated many times. To record detailed program behavior within limited storage space constraints, we propose Near-Omniscient Debugging, a methodology that records an execution trace using fixed size buffers for each observed instruction. Our tool monitors a Java program's execution and annotates source code with observed values in an HTML format. Developers can easily investigate the execution and share the report on a web server. In case of DaCapo benchmark applications, our tool requires fewer than 1% of the complete execution traces to visualize all runtime values used by 66% of instructions that are executed less than 64 times. Developers also can obtain data dependencies with precision 91.8% and recall 79.0% using this tool.","PeriodicalId":106748,"journal":{"name":"2019 IEEE International Conference on Software Maintenance and Evolution (ICSME)","volume":null,"pages":null},"PeriodicalIF":0.0,"publicationDate":"2019-09-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"128059793","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Pub Date : 2019-09-01DOI: 10.1109/ICSME.2019.00086
Mohamed A. Oumaziz, Jean-Rémy Falleri, Xavier Blanc, Tegawendé F. Bissyandé, Jacques Klein
Docker is becoming a popular tool used by developers and end-users to deploy and run software applications. Dockerfiles now belong to software projects as any other software artefacts such as source code or configuration files. Many projects are even starting to maintain families of Dockerfiles rather than a single Dockerfile like the Python project who simultaneously maintains a family of 43 Dockerfiles (specific versions/dependencies). In this paper, we wonder if traditional maintenance challenge of handling duplicates arises in such projects since this challenge is classical in software development, even for non-code software artefacts. Our goal is to provide practitioners a clear explanation for why duplicates arise in projects, and what are the different means to handle duplicates with their pros and cons. To do so, we observe the practices of expert Dockerfile maintainers of Official Docker projects (128 projects) and perform a survey on 25 maintainers from our corpus. We show that duplicates in Dockerfiles are frequent in our corpus, that developers are aware of their existence, are frequently facing them and have a split opinion regarding them (error-prone but easy to maintain with the right tools). Finally, we show that some maintainers manage to limit duplicates by using ad-hoc tools. These tools while sometimes hard to set-up can help reduce the amount of duplicates by up-to 85%.
{"title":"Handling Duplicates in Dockerfiles Families: Learning from Experts","authors":"Mohamed A. Oumaziz, Jean-Rémy Falleri, Xavier Blanc, Tegawendé F. Bissyandé, Jacques Klein","doi":"10.1109/ICSME.2019.00086","DOIUrl":"https://doi.org/10.1109/ICSME.2019.00086","url":null,"abstract":"Docker is becoming a popular tool used by developers and end-users to deploy and run software applications. Dockerfiles now belong to software projects as any other software artefacts such as source code or configuration files. Many projects are even starting to maintain families of Dockerfiles rather than a single Dockerfile like the Python project who simultaneously maintains a family of 43 Dockerfiles (specific versions/dependencies). In this paper, we wonder if traditional maintenance challenge of handling duplicates arises in such projects since this challenge is classical in software development, even for non-code software artefacts. Our goal is to provide practitioners a clear explanation for why duplicates arise in projects, and what are the different means to handle duplicates with their pros and cons. To do so, we observe the practices of expert Dockerfile maintainers of Official Docker projects (128 projects) and perform a survey on 25 maintainers from our corpus. We show that duplicates in Dockerfiles are frequent in our corpus, that developers are aware of their existence, are frequently facing them and have a split opinion regarding them (error-prone but easy to maintain with the right tools). Finally, we show that some maintainers manage to limit duplicates by using ad-hoc tools. These tools while sometimes hard to set-up can help reduce the amount of duplicates by up-to 85%.","PeriodicalId":106748,"journal":{"name":"2019 IEEE International Conference on Software Maintenance and Evolution (ICSME)","volume":null,"pages":null},"PeriodicalIF":0.0,"publicationDate":"2019-09-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"132285590","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Pub Date : 2019-09-01DOI: 10.1109/ICSME.2019.00073
Laura Bello-Jiménez, Alejandro Mazuera-Rozo, M. Linares-Vásquez, G. Bavota
Mobile developers constantly have to deal with users pressure for continuous delivery of apps while keeping quality attributes such as confidentiality and data integrity. To better support developers in testing security vulnerabilities during evolution and maintenance of mobile apps, in this demo we present a novel tool, OPIA, for on-device security testing. OPIA allows developers/testers to (i) conduct SQL-injection attacks and collect logs to identify leaks of sensitive information through record-and-replay testing, and (ii) extract data stored in local databases and shared preferences to identify sensitive information that is not properly encrypted, anonymized. OPIA is publicly available at GitHub.
{"title":"OPIA: A Tool for On-Device Testing of Vulnerabilities in Android Applications","authors":"Laura Bello-Jiménez, Alejandro Mazuera-Rozo, M. Linares-Vásquez, G. Bavota","doi":"10.1109/ICSME.2019.00073","DOIUrl":"https://doi.org/10.1109/ICSME.2019.00073","url":null,"abstract":"Mobile developers constantly have to deal with users pressure for continuous delivery of apps while keeping quality attributes such as confidentiality and data integrity. To better support developers in testing security vulnerabilities during evolution and maintenance of mobile apps, in this demo we present a novel tool, OPIA, for on-device security testing. OPIA allows developers/testers to (i) conduct SQL-injection attacks and collect logs to identify leaks of sensitive information through record-and-replay testing, and (ii) extract data stored in local databases and shared preferences to identify sensitive information that is not properly encrypted, anonymized. OPIA is publicly available at GitHub.","PeriodicalId":106748,"journal":{"name":"2019 IEEE International Conference on Software Maintenance and Evolution (ICSME)","volume":null,"pages":null},"PeriodicalIF":0.0,"publicationDate":"2019-09-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"133983641","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Pub Date : 2019-09-01DOI: 10.1109/ICSME.2019.00038
K. Neupane, Kabo Cheung, Yi Wang
Emotions are an integral part of human nature. Emotion awareness is critical to any form of interpersonal communication and collaboration, including these in the software development process. Recently, the SE community starts having growing interests in emotion awareness in software development. While researchers have accomplished many valuable results, most extant research ignores the dynamic nature of emotion. To investigate the emotion dynamics, SE community needs an effective approach to capture and model emotion dynamics rather than focuses on extracting isolated emotion states. In this paper, we proposed such an approach–EmoD. EmoD is able to automatically collect project teams' communication records, identify the emotions and their intensities in them, model the emotion dynamics into time series, and provide efficient data management. We developed a prototype tool that instantiates the EmoD approach by assembling state-of-the-art NLP, SE, and time series techniques. We demonstrate the utility of the tool using the IPython's project data on GitHub and a visualization solution built on EmoD. Thus, we demonstrate that EmoD can provide end-to-end support for various emotion awareness research and practices through automated data collection, modeling, storage, analysis, and presentation.
{"title":"EmoD: An End-to-End Approach for Investigating Emotion Dynamics in Software Development","authors":"K. Neupane, Kabo Cheung, Yi Wang","doi":"10.1109/ICSME.2019.00038","DOIUrl":"https://doi.org/10.1109/ICSME.2019.00038","url":null,"abstract":"Emotions are an integral part of human nature. Emotion awareness is critical to any form of interpersonal communication and collaboration, including these in the software development process. Recently, the SE community starts having growing interests in emotion awareness in software development. While researchers have accomplished many valuable results, most extant research ignores the dynamic nature of emotion. To investigate the emotion dynamics, SE community needs an effective approach to capture and model emotion dynamics rather than focuses on extracting isolated emotion states. In this paper, we proposed such an approach–EmoD. EmoD is able to automatically collect project teams' communication records, identify the emotions and their intensities in them, model the emotion dynamics into time series, and provide efficient data management. We developed a prototype tool that instantiates the EmoD approach by assembling state-of-the-art NLP, SE, and time series techniques. We demonstrate the utility of the tool using the IPython's project data on GitHub and a visualization solution built on EmoD. Thus, we demonstrate that EmoD can provide end-to-end support for various emotion awareness research and practices through automated data collection, modeling, storage, analysis, and presentation.","PeriodicalId":106748,"journal":{"name":"2019 IEEE International Conference on Software Maintenance and Evolution (ICSME)","volume":null,"pages":null},"PeriodicalIF":0.0,"publicationDate":"2019-09-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"132683905","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Pub Date : 2019-09-01DOI: 10.1109/ICSME.2019.00033
Markos Viggiato, Johnatan Oliveira, Eduardo Figueiredo, Pooyan Jamshidi, Christian Kästner
Code changes are performed differently in the mobile and non-mobile platforms. Prior work has investigated the differences in specific platforms. However, we still lack a deeper understanding of how code changes evolve across different software platforms. In this paper, we present a study aiming at investigating the frequency of changes and how source code, build and test changes co-evolve in mobile and non-mobile platforms. We developed regression models to explain which factors influence the frequency of changes and applied the Apriori algorithm to find types of changes that frequently co-occur. Our findings show that non-mobile repositories have a higher number of commits per month and our regression models suggest that being mobile significantly impacts on the number of commits in a negative direction when controlling for confound factors, such as code size. We also found that developers do not usually change source code files together with build or test files. We argue that our results can provide valuable information for developers on how changes are performed in different platforms so that practices adopted in successful software systems can be followed.
{"title":"How Do Code Changes Evolve in Different Platforms? A Mining-Based Investigation","authors":"Markos Viggiato, Johnatan Oliveira, Eduardo Figueiredo, Pooyan Jamshidi, Christian Kästner","doi":"10.1109/ICSME.2019.00033","DOIUrl":"https://doi.org/10.1109/ICSME.2019.00033","url":null,"abstract":"Code changes are performed differently in the mobile and non-mobile platforms. Prior work has investigated the differences in specific platforms. However, we still lack a deeper understanding of how code changes evolve across different software platforms. In this paper, we present a study aiming at investigating the frequency of changes and how source code, build and test changes co-evolve in mobile and non-mobile platforms. We developed regression models to explain which factors influence the frequency of changes and applied the Apriori algorithm to find types of changes that frequently co-occur. Our findings show that non-mobile repositories have a higher number of commits per month and our regression models suggest that being mobile significantly impacts on the number of commits in a negative direction when controlling for confound factors, such as code size. We also found that developers do not usually change source code files together with build or test files. We argue that our results can provide valuable information for developers on how changes are performed in different platforms so that practices adopted in successful software systems can be followed.","PeriodicalId":106748,"journal":{"name":"2019 IEEE International Conference on Software Maintenance and Evolution (ICSME)","volume":null,"pages":null},"PeriodicalIF":0.0,"publicationDate":"2019-09-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"126238917","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Pub Date : 2019-09-01DOI: 10.1109/ICSME.2019.00029
Martina Iammarino, Fiorella Zampetti, Lerina Aversano, M. D. Penta
Technical Debt (TD) concerns the lack of an adequate solution in a software project, from its design to the source code. Its admittance through comments or commit messages is referred to as Self-Admitted Technical Debt (SATD). Previous research has studied SATD from different perspectives, including its distribution, impact on software quality, and removal. In this paper, we investigate the relationship between refactorings and SATD removal. By leveraging a dataset of SATD and their removals in four open-source projects and by using an automated refactoring detection tool, we study the co-occurrence of refactorings and SATD removals. Results of the study indicate that refactorings are more likely to co-occur with SATD removals than with other commits, however, in most cases, they belong to different quality improvement activities performed at the same time.
{"title":"Self-Admitted Technical Debt Removal and Refactoring Actions: Co-Occurrence or More?","authors":"Martina Iammarino, Fiorella Zampetti, Lerina Aversano, M. D. Penta","doi":"10.1109/ICSME.2019.00029","DOIUrl":"https://doi.org/10.1109/ICSME.2019.00029","url":null,"abstract":"Technical Debt (TD) concerns the lack of an adequate solution in a software project, from its design to the source code. Its admittance through comments or commit messages is referred to as Self-Admitted Technical Debt (SATD). Previous research has studied SATD from different perspectives, including its distribution, impact on software quality, and removal. In this paper, we investigate the relationship between refactorings and SATD removal. By leveraging a dataset of SATD and their removals in four open-source projects and by using an automated refactoring detection tool, we study the co-occurrence of refactorings and SATD removals. Results of the study indicate that refactorings are more likely to co-occur with SATD removals than with other commits, however, in most cases, they belong to different quality improvement activities performed at the same time.","PeriodicalId":106748,"journal":{"name":"2019 IEEE International Conference on Software Maintenance and Evolution (ICSME)","volume":null,"pages":null},"PeriodicalIF":0.0,"publicationDate":"2019-09-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"114865795","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Pub Date : 2019-09-01DOI: 10.1109/ICSME.2019.00083
Effat Farhana, Nasif Imtiaz, A. Rahman
Scientific software is defined as software that is used to analyze data to investigate unanswered research questions in the scientific community. Developers use programming languages such as Julia to build scientific software. When programming with Julia, developers experience program execution time discrepancy i.e. not obtaining desired program execution time, which hinders them to efficiently complete their tasks. The goal of this paper is to help developers in achieving desired program execution time for Julia by identifying the causes of why program execution time discrepancies happen with an empirical study of Stack Overflow posts. We conduct an empirical study with 263 Julia-related posts collected from Stack Overflow, and apply qualitative analysis on the collected 263 posts. We identify 9 categories of program execution time discrepancies for Julia, which include discrepancies related to data structures usage such as, arrays and dictionaries. We also identify 10 causes that explain why the program execution time discrepancies happen. For example, we identify program execution time discrepancy to happen when developers unnecessarily allocate memory by using array comprehension.
{"title":"Synthesizing Program Execution Time Discrepancies in Julia Used for Scientific Software","authors":"Effat Farhana, Nasif Imtiaz, A. Rahman","doi":"10.1109/ICSME.2019.00083","DOIUrl":"https://doi.org/10.1109/ICSME.2019.00083","url":null,"abstract":"Scientific software is defined as software that is used to analyze data to investigate unanswered research questions in the scientific community. Developers use programming languages such as Julia to build scientific software. When programming with Julia, developers experience program execution time discrepancy i.e. not obtaining desired program execution time, which hinders them to efficiently complete their tasks. The goal of this paper is to help developers in achieving desired program execution time for Julia by identifying the causes of why program execution time discrepancies happen with an empirical study of Stack Overflow posts. We conduct an empirical study with 263 Julia-related posts collected from Stack Overflow, and apply qualitative analysis on the collected 263 posts. We identify 9 categories of program execution time discrepancies for Julia, which include discrepancies related to data structures usage such as, arrays and dictionaries. We also identify 10 causes that explain why the program execution time discrepancies happen. For example, we identify program execution time discrepancy to happen when developers unnecessarily allocate memory by using array comprehension.","PeriodicalId":106748,"journal":{"name":"2019 IEEE International Conference on Software Maintenance and Evolution (ICSME)","volume":null,"pages":null},"PeriodicalIF":0.0,"publicationDate":"2019-09-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"122305540","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Pub Date : 2019-09-01DOI: 10.1109/icsme.2019.00001
{"title":"[Title page i]","authors":"","doi":"10.1109/icsme.2019.00001","DOIUrl":"https://doi.org/10.1109/icsme.2019.00001","url":null,"abstract":"","PeriodicalId":106748,"journal":{"name":"2019 IEEE International Conference on Software Maintenance and Evolution (ICSME)","volume":null,"pages":null},"PeriodicalIF":0.0,"publicationDate":"2019-09-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"132783059","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Pub Date : 2019-09-01DOI: 10.1109/ICSME.2019.00079
Chen Zhi, Jianwei Yin, Shuiguang Deng, Maoxin Ye, Min Fu, Tao Xie
Logging components are an integral element of software systems. These logging components receive the logging requests generated by the logging code and process these requests according to logging configurations. Logging configurations play an important role on the functionality, performance, and reliability of logging. Although recent research has been conducted to understand and improve current practice on logging code, no existing research focuses on logging configurations. To fill this gap, we conduct an exploratory study on logging configuration practice of 10 open-source projects and 10 industrial projects written in Java in various sizes and domains. We quantitatively show how logging configurations are used with respect to logging management, storage, and formatting. We categorize and analyze the change history (1,213 revisions) of logging configurations to understand how the logging configurations evolve. Based on these study results, we reveal 10 findings about current practice of logging configurations. As a proof of concept, we develop a simple detector based on some of our findings. We apply our detector on three popular open-source projects and identify three long-lived issues (more than two years). All these issues are confirmed and two of them have been fixed by the open-source developers.
{"title":"An Exploratory Study of Logging Configuration Practice in Java","authors":"Chen Zhi, Jianwei Yin, Shuiguang Deng, Maoxin Ye, Min Fu, Tao Xie","doi":"10.1109/ICSME.2019.00079","DOIUrl":"https://doi.org/10.1109/ICSME.2019.00079","url":null,"abstract":"Logging components are an integral element of software systems. These logging components receive the logging requests generated by the logging code and process these requests according to logging configurations. Logging configurations play an important role on the functionality, performance, and reliability of logging. Although recent research has been conducted to understand and improve current practice on logging code, no existing research focuses on logging configurations. To fill this gap, we conduct an exploratory study on logging configuration practice of 10 open-source projects and 10 industrial projects written in Java in various sizes and domains. We quantitatively show how logging configurations are used with respect to logging management, storage, and formatting. We categorize and analyze the change history (1,213 revisions) of logging configurations to understand how the logging configurations evolve. Based on these study results, we reveal 10 findings about current practice of logging configurations. As a proof of concept, we develop a simple detector based on some of our findings. We apply our detector on three popular open-source projects and identify three long-lived issues (more than two years). All these issues are confirmed and two of them have been fixed by the open-source developers.","PeriodicalId":106748,"journal":{"name":"2019 IEEE International Conference on Software Maintenance and Evolution (ICSME)","volume":null,"pages":null},"PeriodicalIF":0.0,"publicationDate":"2019-09-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"133386945","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Pub Date : 2019-09-01DOI: 10.1109/ICSME.2019.00069
Nystrom Edwards, Dhitiwat Jongsuebchoke, Tim Storer
This paper presents sciit, a distributed issue tracker. Distributed issue tracking eliminates much of the friction that is otherwise necessitated by separately maintaining source code in a distributed source control management system (SCM) and task information in a centralised issue tracker. Sciit goes beyond the state of the art in distributed issue tracking by treating issues as first class change control items, represented as fragments of text anywhere within the SCM. This approach treats issues as representations of work in progress alongside other project artefacts. This alignment allows much of the meta-data about an issue, such as status, affected components and participants to be inferred directly from the state of the SCM, rather than requiring maintenance of this information by a developer. The paper presents a scenario to illustrate the benefits of sciit and an outline of the tool's architecture.
{"title":"Sciit: Aligning Source Control Management and Issue Tracking Architectures","authors":"Nystrom Edwards, Dhitiwat Jongsuebchoke, Tim Storer","doi":"10.1109/ICSME.2019.00069","DOIUrl":"https://doi.org/10.1109/ICSME.2019.00069","url":null,"abstract":"This paper presents sciit, a distributed issue tracker. Distributed issue tracking eliminates much of the friction that is otherwise necessitated by separately maintaining source code in a distributed source control management system (SCM) and task information in a centralised issue tracker. Sciit goes beyond the state of the art in distributed issue tracking by treating issues as first class change control items, represented as fragments of text anywhere within the SCM. This approach treats issues as representations of work in progress alongside other project artefacts. This alignment allows much of the meta-data about an issue, such as status, affected components and participants to be inferred directly from the state of the SCM, rather than requiring maintenance of this information by a developer. The paper presents a scenario to illustrate the benefits of sciit and an outline of the tool's architecture.","PeriodicalId":106748,"journal":{"name":"2019 IEEE International Conference on Software Maintenance and Evolution (ICSME)","volume":null,"pages":null},"PeriodicalIF":0.0,"publicationDate":"2019-09-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"126896095","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
京公网安备 11010802042870号
京ICP备2023020795号-1
扫码关注我们
求助内容：
应助结果提醒方式：