Icse2011 src
•
0 likes•121 views
This document discusses build system maintenance. It notes that build systems require 12% of a developer's time on average and that build maintenance slows development. The document presents a four-dimensional study of build maintenance that examined size, evolution, coupling and people dimensions. It found that build churn was greater than source code churn. The document also discusses whether build ownership is dispersed amongst many developers or concentrated within a small team. It concludes that tool support is needed to help with build maintenance tasks.
Report
Share
Report
Share
Download to read offline
Recommended
Where is CEO?
We opened 1'st hackathon in Flitto.
My project is to know What floor CEO is located at.
It consists of Express framework of Nodejs.
Icse2011 build maintenance
This study analyzed 10 large open source projects to understand build system maintenance effort. It found that build systems accounted for around 9% of total files on average. Build code evolved at a similar rate to source code, with some projects experiencing higher build churn. Changes to build and source code were often logically coupled, with some work items affecting both. Responsibility for build maintenance was usually distributed across developers rather than concentrated in a small team. The findings suggest build systems require significant effort to maintain and that tool support could help address this.
My Sister's Keeper Variety
1. The document provides box office results for the weekend of August 27-29, 2004. Hero was the top-grossing film with $18 million, followed by Anacondas: The Hunt for the Blood Orchid with $12.8 million.
2. It also includes Nielsen ratings results for the top television shows on Tuesday, August 10, 2004. The Amazing Race 5 on CBS had the largest total viewership with 10.8 million. In the 18-49 demographic, The Amazing Race 5 also led with a 4.8 rating.
3. Additional details provided include preliminary Nielsen ratings results for the top networks on August 10, with CBS having the highest average rating of 3.
Apn log
This document contains log entries showing the execution of various functions on August 8th, 2012, including encoding data, getting the default browser, checking for Flash versions, and disabling and reverting filesystem redirection. The same set of functions were executed twice at 14:31:38 and again at 14:31:42.
Apres le bac pro Productions aquacoles
This summary provides the key details from the document in 3 sentences:
The document discusses the career path of graduates from the BTS Agricultural Technician program over 2 years after graduating in 2018. It describes their employment outcomes, with most graduates pursuing further education and training in agricultural fields. The document also outlines the contents of the BTS Agricultural Technician program curriculum and specialized training areas after the first year.
เจ้าหน้าที่บริหารงานคอมพิวเตอร์
and include only the most important details while preserving the core meaning of the original document.
3. Examples are provided of summaries that meet this criteria.
Trending #Empathy
DISCLAIMER: sorry for the resolution, miscreant files and stubborn computers!
This is a look at the coincidental drop of empathy in college students during the rise of technology.
Electronic Fruits have taken over!
Uncover43 (Marp Next custom theme)
This document contains a sample slide deck converted from Markdown by Marp Next. It demonstrates various Markdown elements like lists, tables, figures, code blocks, and math equations that are commonly found in technical slide decks. The slide deck contains 6 pages showing examples of these different elements.
Recommended
Where is CEO?
We opened 1'st hackathon in Flitto.
My project is to know What floor CEO is located at.
It consists of Express framework of Nodejs.
Icse2011 build maintenance
This study analyzed 10 large open source projects to understand build system maintenance effort. It found that build systems accounted for around 9% of total files on average. Build code evolved at a similar rate to source code, with some projects experiencing higher build churn. Changes to build and source code were often logically coupled, with some work items affecting both. Responsibility for build maintenance was usually distributed across developers rather than concentrated in a small team. The findings suggest build systems require significant effort to maintain and that tool support could help address this.
My Sister's Keeper Variety
1. The document provides box office results for the weekend of August 27-29, 2004. Hero was the top-grossing film with $18 million, followed by Anacondas: The Hunt for the Blood Orchid with $12.8 million.
2. It also includes Nielsen ratings results for the top television shows on Tuesday, August 10, 2004. The Amazing Race 5 on CBS had the largest total viewership with 10.8 million. In the 18-49 demographic, The Amazing Race 5 also led with a 4.8 rating.
3. Additional details provided include preliminary Nielsen ratings results for the top networks on August 10, with CBS having the highest average rating of 3.
Apn log
This document contains log entries showing the execution of various functions on August 8th, 2012, including encoding data, getting the default browser, checking for Flash versions, and disabling and reverting filesystem redirection. The same set of functions were executed twice at 14:31:38 and again at 14:31:42.
Apres le bac pro Productions aquacoles
This summary provides the key details from the document in 3 sentences:
The document discusses the career path of graduates from the BTS Agricultural Technician program over 2 years after graduating in 2018. It describes their employment outcomes, with most graduates pursuing further education and training in agricultural fields. The document also outlines the contents of the BTS Agricultural Technician program curriculum and specialized training areas after the first year.
เจ้าหน้าที่บริหารงานคอมพิวเตอร์
and include only the most important details while preserving the core meaning of the original document.
3. Examples are provided of summaries that meet this criteria.
Trending #Empathy
DISCLAIMER: sorry for the resolution, miscreant files and stubborn computers!
This is a look at the coincidental drop of empathy in college students during the rise of technology.
Electronic Fruits have taken over!
Uncover43 (Marp Next custom theme)
This document contains a sample slide deck converted from Markdown by Marp Next. It demonstrates various Markdown elements like lists, tables, figures, code blocks, and math equations that are commonly found in technical slide decks. The slide deck contains 6 pages showing examples of these different elements.
ICPE2015
Our approach uses regression models on clustered performance counters to automatically detect performance regressions. It reduces counters, clusters remaining counters, selects target counters showing most significant differences between versions, and builds regression models to predict counters in the new version. When applied to real systems, our approach picks a small number of target counters and can accurately detect performance regressions, outperforming traditional approaches.
Msr2016 tarek
This document discusses using Application Performance Management (APM) tools to detect performance regressions in web applications. It presents a case study where performance regressions were injected into test systems and then evaluated whether commercial and open source APM tools could detect the issues. The study found that APM tools can successfully detect some performance regressions, but they have limitations like producing large reports that require manual exploration and lacking actionable suggestions for fixes. The document concludes that APM tools show promise as a way to deploy performance regression detection research into practice.
ICSE2013
This document proposes an approach to assist developers in verifying the deployment of big data analytics applications on Hadoop clouds. The approach involves three main steps: 1) log abstraction reduces the size of logs by grouping similar log lines, 2) log linking provides context by linking logs with the same task IDs, and 3) sequence simplification deals with repeated logs by removing duplicate events. This helps address issues like the large amount of log data and lack of context when verifying applications at scale in cloud environments.
ASE2010
This document reports on scaling tools for mining software repositories (MSR) studies using MapReduce. It finds that MapReduce can effectively scale three large MSR studies - a software evolution study, code clone detection, and log analysis - to larger datasets and clusters of up to 28 machines. The main challenges in migrating MSR studies to MapReduce are the locality and granularity of the analysis, locating a suitable cluster, managing large datasets, and handling errors.
MSR 2009
The document proposes using MapReduce as a general framework to support research in mining software repositories (MSR). It describes how MapReduce can provide efficiency, scalability, adaptability and flexibility for common MSR tasks like analyzing large code repositories. A case study of applying MapReduce to the J-REX MSR tool shows significant reductions in running time for large datasets. Minimal programming effort was required and MapReduce could run on various computing environments.
ICSME2014
The document describes a study on understanding log lines using development knowledge from source code. The researchers examined real-life inquiries about log lines from user mailing lists and logs of three large software systems. They found that experts are crucial in resolving log inquiries, with 8 out of 11 resolved inquiries addressed by experts. The researchers propose attaching development knowledge like source code, code comments, and issue reports to logs to help practitioners understand log messages without relying on expert assistance. An example demonstrates how different types of development knowledge can help explain the meaning, cause, impact and solution for the log message "fetch failure".
ICSE2014
This document discusses an approach for detecting performance anti-patterns in applications developed using Object-Relational Mapping (ORM). It presents a framework that can detect and rank performance anti-patterns based on their expected impact. As an example, it describes how the framework can detect an excessive data anti-pattern where ORM configurations eagerly retrieve data from the database that is never used. Repeated measurements are used to quantify the actual performance impact of anti-patterns by fixing the issues. The framework was evaluated on several open-source systems where it identified hundreds of potential excessive data anti-patterns.
ICSE2011_SRC
The document discusses build system maintenance. It notes that build code is complex and requires 12% of a developer's time on average. Build bugs can affect end users. Four dimensions of build maintenance are discussed: size, evolution, coupling, and people involvement. Studies found that build churn is greater than source code churn, and that build maintenance is often dispersed across many team members rather than concentrated in a small team. Tool support is needed to help with build maintenance tasks.
Mining Co-Change Information to Understand when Build Changes are Necessary
As a software project ages, its source code is modified to add new features, restructure existing ones, and fix defects. These source code changes often induce changes in the build system, i.e., the system that specifies how source code is translated into deliverables. However, since developers are often not familiar with the complex and occasionally archaic technologies used to specify build systems, they may not be able to identify when their source code changes require accompanying build system changes. This can cause build breakages that slow development progress and impact other developers, testers, or even users. In this paper, we mine the source and test code changes that required accompanying build changes in order to better understand this co-change relationship. We build random forest classifiers using language-agnostic and language-specific code change characteristics to explain when code-accompanying build changes are necessary based on historical trends. Case studies of the Mozilla C++ system, the Lucene and Eclipse open source Java systems, and the IBM Jazz proprietary Java system indicate that our classifiers can accurately explain when build co-changes are necessary with an AUC of 0.60-0.88. Unsurprisingly, our highly accurate C++ classifiers (AUC of 0.88) derive much of their explanatory power from indicators of structural change (e.g., was a new source file added?). On the other hand, our Java classifiers are less accurate (AUC of 0.60-0.78) because roughly 75% of Java build co-changes do not coincide with changes to the structure of a system, but rather are instigated by concerns related to release engineering, quality assurance, and general build maintenance.
Tracing Software Build Processes to Uncover License Compliance Inconsistencies
Open Source Software (OSS) components form the basis for many software systems. While the use of OSS components accelerates development, client systems must comply with the license terms of the OSS components that they use. Failure to do so exposes client system distributors to possible litigation from copyright holders. Yet despite the importance of license compliance, tool support for license compliance assessment is lacking. In this paper, we propose an approach to extract and analyze the Concrete Build Dependency Graph (CBDG) of a software system by tracing system calls that occur at build-time. Through a case study of seven open source systems, we show that the extracted CBDGs: (1) accurately classify sources as included in or excluded from deliverables with 88%-100% precision and 98%-100% recall, and (2) can uncover license compliance inconsistencies in real software systems - two of which prompted code fixes in the CUPS and FFmpeg systems.
Identifying Hotspots in the PostgreSQL Build Process
Software developers rely on a fast and correct build system to compile their source code changes and produce modified deliverables for testing and deployment. The scale and complexity of the PostgreSQL build process makes build performance an important topic to discuss and address.
In this talk, we will introduce a new build performance analysis technique that identifies "build hotspots", i.e., files that are slow to rebuild (by analyzing a build dependency graph), yet change often (by analyzing version control history). We will discuss the identified hotspots in the 9.2.4 release of PostgreSQL.
Modern Release Engineering in a Nutshell - Why Researchers should Care!
Invited talk at the Leaders of Tomorrow Symposium of the 23rd IEEE International Conference on Software Analysis, Evolution, and Reengineering (SANER 2016).
The presentation (and its accompanying paper, see http://mcis.polymtl.ca/publications/2016/fose.pdf) explain the basics of release engineering pipelines, common challenges industry is facing as well as pitfalls software engineering researchers are falling into.
Speakers are Bram Adams (MCIS, http://mcis.polymtl.ca) and Shane McIntosh (McGill University, http://shanemcintosh.org).
A video-taped version of the talk will be available soon at https://www.youtube.com/channel/UCL8yG6qpHk7V66l1Jt3aZrA/featured.
Relational Database CI/CD
Talk at DevOps Meetup in Stuttgart about Continuous Integration and Continuous Delivery of relational databases.
Studying the Evolution of Build Systems
This document summarizes a study on the evolution of build systems. The study analyzed two open source projects to understand how build systems change over time at both high and fine-grained levels. At a high level, the size and complexity of build systems were found to evolve similarly to source code, and build times tended to increase with project age. At a fine-grained level, build systems consisted of around 9% of total files, experienced churn on par with source code, and changes typically added or deleted 3-4 lines. Further, up to 27% of development tasks required build changes, and build maintenance work was found to be dispersed across most team members rather than concentrated in a small group.
Tracing Software Build Processes to Uncover License Compliance Inconsistencie...
This document discusses using build systems to uncover license compliance inconsistencies. It describes how build systems can be traced to construct dependency graphs and annotate components with license information. An empirical study found the approach accurately discovered inconsistencies with 88-100% precision and 98-100% recall. The technique prompted code changes in two systems within a few days to resolve license issues uncovered.
Cross-Project Build Co-change Prediction
Build systems orchestrate how human-readable source code is translated into executable programs. In a software project, source code changes can induce changes in the build system (aka. build co-changes). It is difficult for developers to identify when build co-changes are necessary due to the complexity of build systems. Prediction of build co-changes works well if there is a sufficient amount of training data to build a model. However, in practice, for new projects, there exists a limited number of changes. Using training data from other projects to predict the build co-changes in a new project can help improve the performance of the build co-change prediction. We refer to this problem as cross-project build co-change prediction.
In this paper, we propose CroBuild, a novel cross-project build co-change prediction approach that iteratively learns new classifiers. CroBuild constructs an ensemble of classifiers by iteratively building classifiers and assigning them weights according to its prediction error rate. Given that only a small proportion of code changes are build co-changing, we also propose an imbalance-aware approach that learns a threshold boundary between those code changes that are build co-changing and those that are not in order to construct classifiers in each iteration. To examine the benefits of CroBuild, we perform experiments on 4 large datasets including Mozilla, Eclipse-core, Lucene, and Jazz, comprising a total of 50,884 changes. On average, across the 4 datasets, CroBuild achieves a F1-score of up to 0.408. We also compare CroBuild with other approaches such as a basic model, AdaBoost proposed by Freund et al., and TrAdaBoost proposed by Dai et al.. On average, across the 4 datasets, the CroBuild approach yields an improvement in F1-scores of 41.54%, 36.63%, and 36.97% over the basic model, AdaBoost, and TrAdaBoost, respectively.
The Science of database CICD - UKOUG Breakthrough
Talk about CI/CD of database applications explaining which elements are necessary to build robust CI/CD pipelines.
Keeping Master Green at Scale
The document describes techniques used by Uber to keep their monorepo's master branch always green at scale. It discusses how concurrent changes can cause the master to become red, hampering productivity. The Submit Queue system uses speculation graphs and a conflict analyzer to serially commit changes while maximizing parallelism. It speculates on possible outcomes to minimize necessary builds. The conflict analyzer identifies independent changes to reduce speculation and commit changes in parallel. An evaluation shows Submit Queue outperforms alternative strategies and closely matches an oracle's performance.
BlackHat 2014 Briefings - Exploiting Fundamental Weaknesses in Botnet C&C Pan...
Bot herders deploy Command and Control (C&C) panels for commanding and collecting exfiltrated data from the infected hosts on the Internet. To protect C&C panels, bot herders deploy several built-in (software-centric) protection mechanisms to restrict direct access to these C&C panels. However, there exist fundamental mistakes in the design and deployment of these C&C panels that can be exploited to take complete control. This talk discusses about the methodology of launching reverse attacks on the centralized C&C panels to derive intelligence that can be used to build automated solutions. This research reveals how to detect vulnerabilities and configuration flaws in the remote C&C panels and exploit them by following the path of penetration testing. This talk is derived from the real time research in which several C&C panels were targeted and intelligence was gathered to attack the next set of C&C panels. A number of case studies will be discussed to elaborate step-by-step process of attacking and compromising C&C panels. This talk also demonstrates the use of automated tools authored for making the testing easier for the researchers.
DOWNLOAD from this link : http://secniche.org/blackhat-2014/
An Empirical Analysis of Build Failures in the Continuous Integration Workflo...
This document analyzes build failures in the continuous integration workflows of Java-based open source software projects. It categorizes common error types that cause build failures, such as compilation errors, test failures, dependency errors and crashes. It also uses statistical analysis to study factors that may be associated with build failures, such as change metrics, previous build results, and pull request scenarios. A key finding is that build failures often occur consecutively, indicating phases of instability that perpetuate failures. The analysis provides insights into challenges of mining continuous integration data and understanding the causes of build failures.
ABCDs of Database Development
Always Be Continuously Delivering! Short introduction to Continuous Delivery and creating a deployment pipeline.
Abstract: Databases often sit outside Continuous Delivery for a variety of reasons, good and bad. But if you want fast and reliable deployments, the database cannot remain separate. We’ll talk through the challenges and look at tools to automate database delivery, highlighting open source options. I’ll live demo a database change flowing to ‘production,’ giving a clear picture of a fully automated process. The session is for developers, ops people, and managers, who will come out understanding how to customise practices and toolsets, building a pipeline suited to their environment. The result will accelerate database delivery, while protecting the organisation’s most valuable asset: its data.
More Related Content
Viewers also liked
ICPE2015
Our approach uses regression models on clustered performance counters to automatically detect performance regressions. It reduces counters, clusters remaining counters, selects target counters showing most significant differences between versions, and builds regression models to predict counters in the new version. When applied to real systems, our approach picks a small number of target counters and can accurately detect performance regressions, outperforming traditional approaches.
Msr2016 tarek
This document discusses using Application Performance Management (APM) tools to detect performance regressions in web applications. It presents a case study where performance regressions were injected into test systems and then evaluated whether commercial and open source APM tools could detect the issues. The study found that APM tools can successfully detect some performance regressions, but they have limitations like producing large reports that require manual exploration and lacking actionable suggestions for fixes. The document concludes that APM tools show promise as a way to deploy performance regression detection research into practice.
ICSE2013
This document proposes an approach to assist developers in verifying the deployment of big data analytics applications on Hadoop clouds. The approach involves three main steps: 1) log abstraction reduces the size of logs by grouping similar log lines, 2) log linking provides context by linking logs with the same task IDs, and 3) sequence simplification deals with repeated logs by removing duplicate events. This helps address issues like the large amount of log data and lack of context when verifying applications at scale in cloud environments.
ASE2010
This document reports on scaling tools for mining software repositories (MSR) studies using MapReduce. It finds that MapReduce can effectively scale three large MSR studies - a software evolution study, code clone detection, and log analysis - to larger datasets and clusters of up to 28 machines. The main challenges in migrating MSR studies to MapReduce are the locality and granularity of the analysis, locating a suitable cluster, managing large datasets, and handling errors.
MSR 2009
The document proposes using MapReduce as a general framework to support research in mining software repositories (MSR). It describes how MapReduce can provide efficiency, scalability, adaptability and flexibility for common MSR tasks like analyzing large code repositories. A case study of applying MapReduce to the J-REX MSR tool shows significant reductions in running time for large datasets. Minimal programming effort was required and MapReduce could run on various computing environments.
ICSME2014
The document describes a study on understanding log lines using development knowledge from source code. The researchers examined real-life inquiries about log lines from user mailing lists and logs of three large software systems. They found that experts are crucial in resolving log inquiries, with 8 out of 11 resolved inquiries addressed by experts. The researchers propose attaching development knowledge like source code, code comments, and issue reports to logs to help practitioners understand log messages without relying on expert assistance. An example demonstrates how different types of development knowledge can help explain the meaning, cause, impact and solution for the log message "fetch failure".
ICSE2014
This document discusses an approach for detecting performance anti-patterns in applications developed using Object-Relational Mapping (ORM). It presents a framework that can detect and rank performance anti-patterns based on their expected impact. As an example, it describes how the framework can detect an excessive data anti-pattern where ORM configurations eagerly retrieve data from the database that is never used. Repeated measurements are used to quantify the actual performance impact of anti-patterns by fixing the issues. The framework was evaluated on several open-source systems where it identified hundreds of potential excessive data anti-patterns.
Similar to Icse2011 src
ICSE2011_SRC
The document discusses build system maintenance. It notes that build code is complex and requires 12% of a developer's time on average. Build bugs can affect end users. Four dimensions of build maintenance are discussed: size, evolution, coupling, and people involvement. Studies found that build churn is greater than source code churn, and that build maintenance is often dispersed across many team members rather than concentrated in a small team. Tool support is needed to help with build maintenance tasks.
Mining Co-Change Information to Understand when Build Changes are Necessary
As a software project ages, its source code is modified to add new features, restructure existing ones, and fix defects. These source code changes often induce changes in the build system, i.e., the system that specifies how source code is translated into deliverables. However, since developers are often not familiar with the complex and occasionally archaic technologies used to specify build systems, they may not be able to identify when their source code changes require accompanying build system changes. This can cause build breakages that slow development progress and impact other developers, testers, or even users. In this paper, we mine the source and test code changes that required accompanying build changes in order to better understand this co-change relationship. We build random forest classifiers using language-agnostic and language-specific code change characteristics to explain when code-accompanying build changes are necessary based on historical trends. Case studies of the Mozilla C++ system, the Lucene and Eclipse open source Java systems, and the IBM Jazz proprietary Java system indicate that our classifiers can accurately explain when build co-changes are necessary with an AUC of 0.60-0.88. Unsurprisingly, our highly accurate C++ classifiers (AUC of 0.88) derive much of their explanatory power from indicators of structural change (e.g., was a new source file added?). On the other hand, our Java classifiers are less accurate (AUC of 0.60-0.78) because roughly 75% of Java build co-changes do not coincide with changes to the structure of a system, but rather are instigated by concerns related to release engineering, quality assurance, and general build maintenance.
Tracing Software Build Processes to Uncover License Compliance Inconsistencies
Open Source Software (OSS) components form the basis for many software systems. While the use of OSS components accelerates development, client systems must comply with the license terms of the OSS components that they use. Failure to do so exposes client system distributors to possible litigation from copyright holders. Yet despite the importance of license compliance, tool support for license compliance assessment is lacking. In this paper, we propose an approach to extract and analyze the Concrete Build Dependency Graph (CBDG) of a software system by tracing system calls that occur at build-time. Through a case study of seven open source systems, we show that the extracted CBDGs: (1) accurately classify sources as included in or excluded from deliverables with 88%-100% precision and 98%-100% recall, and (2) can uncover license compliance inconsistencies in real software systems - two of which prompted code fixes in the CUPS and FFmpeg systems.
Identifying Hotspots in the PostgreSQL Build Process
Software developers rely on a fast and correct build system to compile their source code changes and produce modified deliverables for testing and deployment. The scale and complexity of the PostgreSQL build process makes build performance an important topic to discuss and address.
In this talk, we will introduce a new build performance analysis technique that identifies "build hotspots", i.e., files that are slow to rebuild (by analyzing a build dependency graph), yet change often (by analyzing version control history). We will discuss the identified hotspots in the 9.2.4 release of PostgreSQL.
Modern Release Engineering in a Nutshell - Why Researchers should Care!
Invited talk at the Leaders of Tomorrow Symposium of the 23rd IEEE International Conference on Software Analysis, Evolution, and Reengineering (SANER 2016).
The presentation (and its accompanying paper, see http://mcis.polymtl.ca/publications/2016/fose.pdf) explain the basics of release engineering pipelines, common challenges industry is facing as well as pitfalls software engineering researchers are falling into.
Speakers are Bram Adams (MCIS, http://mcis.polymtl.ca) and Shane McIntosh (McGill University, http://shanemcintosh.org).
A video-taped version of the talk will be available soon at https://www.youtube.com/channel/UCL8yG6qpHk7V66l1Jt3aZrA/featured.
Relational Database CI/CD
Talk at DevOps Meetup in Stuttgart about Continuous Integration and Continuous Delivery of relational databases.
Studying the Evolution of Build Systems
This document summarizes a study on the evolution of build systems. The study analyzed two open source projects to understand how build systems change over time at both high and fine-grained levels. At a high level, the size and complexity of build systems were found to evolve similarly to source code, and build times tended to increase with project age. At a fine-grained level, build systems consisted of around 9% of total files, experienced churn on par with source code, and changes typically added or deleted 3-4 lines. Further, up to 27% of development tasks required build changes, and build maintenance work was found to be dispersed across most team members rather than concentrated in a small group.
Tracing Software Build Processes to Uncover License Compliance Inconsistencie...
This document discusses using build systems to uncover license compliance inconsistencies. It describes how build systems can be traced to construct dependency graphs and annotate components with license information. An empirical study found the approach accurately discovered inconsistencies with 88-100% precision and 98-100% recall. The technique prompted code changes in two systems within a few days to resolve license issues uncovered.
Cross-Project Build Co-change Prediction
Build systems orchestrate how human-readable source code is translated into executable programs. In a software project, source code changes can induce changes in the build system (aka. build co-changes). It is difficult for developers to identify when build co-changes are necessary due to the complexity of build systems. Prediction of build co-changes works well if there is a sufficient amount of training data to build a model. However, in practice, for new projects, there exists a limited number of changes. Using training data from other projects to predict the build co-changes in a new project can help improve the performance of the build co-change prediction. We refer to this problem as cross-project build co-change prediction.
In this paper, we propose CroBuild, a novel cross-project build co-change prediction approach that iteratively learns new classifiers. CroBuild constructs an ensemble of classifiers by iteratively building classifiers and assigning them weights according to its prediction error rate. Given that only a small proportion of code changes are build co-changing, we also propose an imbalance-aware approach that learns a threshold boundary between those code changes that are build co-changing and those that are not in order to construct classifiers in each iteration. To examine the benefits of CroBuild, we perform experiments on 4 large datasets including Mozilla, Eclipse-core, Lucene, and Jazz, comprising a total of 50,884 changes. On average, across the 4 datasets, CroBuild achieves a F1-score of up to 0.408. We also compare CroBuild with other approaches such as a basic model, AdaBoost proposed by Freund et al., and TrAdaBoost proposed by Dai et al.. On average, across the 4 datasets, the CroBuild approach yields an improvement in F1-scores of 41.54%, 36.63%, and 36.97% over the basic model, AdaBoost, and TrAdaBoost, respectively.
The Science of database CICD - UKOUG Breakthrough
Talk about CI/CD of database applications explaining which elements are necessary to build robust CI/CD pipelines.
Keeping Master Green at Scale
The document describes techniques used by Uber to keep their monorepo's master branch always green at scale. It discusses how concurrent changes can cause the master to become red, hampering productivity. The Submit Queue system uses speculation graphs and a conflict analyzer to serially commit changes while maximizing parallelism. It speculates on possible outcomes to minimize necessary builds. The conflict analyzer identifies independent changes to reduce speculation and commit changes in parallel. An evaluation shows Submit Queue outperforms alternative strategies and closely matches an oracle's performance.
BlackHat 2014 Briefings - Exploiting Fundamental Weaknesses in Botnet C&C Pan...
Bot herders deploy Command and Control (C&C) panels for commanding and collecting exfiltrated data from the infected hosts on the Internet. To protect C&C panels, bot herders deploy several built-in (software-centric) protection mechanisms to restrict direct access to these C&C panels. However, there exist fundamental mistakes in the design and deployment of these C&C panels that can be exploited to take complete control. This talk discusses about the methodology of launching reverse attacks on the centralized C&C panels to derive intelligence that can be used to build automated solutions. This research reveals how to detect vulnerabilities and configuration flaws in the remote C&C panels and exploit them by following the path of penetration testing. This talk is derived from the real time research in which several C&C panels were targeted and intelligence was gathered to attack the next set of C&C panels. A number of case studies will be discussed to elaborate step-by-step process of attacking and compromising C&C panels. This talk also demonstrates the use of automated tools authored for making the testing easier for the researchers.
DOWNLOAD from this link : http://secniche.org/blackhat-2014/
An Empirical Analysis of Build Failures in the Continuous Integration Workflo...
This document analyzes build failures in the continuous integration workflows of Java-based open source software projects. It categorizes common error types that cause build failures, such as compilation errors, test failures, dependency errors and crashes. It also uses statistical analysis to study factors that may be associated with build failures, such as change metrics, previous build results, and pull request scenarios. A key finding is that build failures often occur consecutively, indicating phases of instability that perpetuate failures. The analysis provides insights into challenges of mining continuous integration data and understanding the causes of build failures.
ABCDs of Database Development
Always Be Continuously Delivering! Short introduction to Continuous Delivery and creating a deployment pipeline.
Abstract: Databases often sit outside Continuous Delivery for a variety of reasons, good and bad. But if you want fast and reliable deployments, the database cannot remain separate. We’ll talk through the challenges and look at tools to automate database delivery, highlighting open source options. I’ll live demo a database change flowing to ‘production,’ giving a clear picture of a fully automated process. The session is for developers, ops people, and managers, who will come out understanding how to customise practices and toolsets, building a pipeline suited to their environment. The result will accelerate database delivery, while protecting the organisation’s most valuable asset: its data.
Data Mining-based Tools to Support Library Update. PhD Defence of Oleksandr Z...
Oleksandr ZAITSEV obtaining PhD in Informatics from the University of Lille.
Title: Data Mining-based Tools to Support Library Update
Date: October 28, 2022
Location: Inria Lille - Nord Europe. Park Plaza, Parc scientifique de la Haute-Borne, 6 Rue Heloïse Bât B, 59650 Villeneuve-d'Ascq, France
Composition of the jury:
Supervisor: Stéphane DUCASSE
Co-supervisor: Nicolas ANQUETIL
Industrial advisor: Arnaud THIEFAINE
Reviewers: Romain ROBBES, Coen de ROOVER
Examiner: Olga KOUCHNARENKO
This was a Cifre PhD between Inria research institute and Arolla software company. Oleksandr ZAITSEV is grateful to Arolla for sponsoring his research.
Digging into your DevTools
This talk takes a brief look at developer tooling history, before jumping into a breakdown of some of Chrome DevTools major panels and tricks and techniques for each area. We then took two live examples of JS debugging with multiple kinds of breakpoints, and then wrapped things up with a quick overview of the RAIL performance model, and a walkthrough and demo of the Performance and Audit panels to see how we can catch performance bottlenecks and fix them!
DevOps: Find Solutions, Not More Defects
The promise of DevOps is that we can push new ideas out to market faster while avoiding delivering serious defects into production. Andreas Grabner explains that testers are no longer measured by the number of defect reports they enter, nor are developers measured by the lines of code they write. As a team, you are measured by how fast you can deploy high quality functionality to the end user. Achieving this goal requires testers to increase their skills. It’s all about finding solutions—not just problems. Testers must transition from reporting “app crashes” to providing details such as “memory leak caused by bad cache implementation.” Instead of reporting “it’s slow,” testers must discover “wrong hibernate configuration causes too much traffic from the database.” Using three real-life examples, Andreas illustrates what it takes for testing teams to become part of the DevOps transformation—bringing more value to the entire organization.
Improving Code Quality In Medical Software Through Code Reviews - Vincit Teat...
The document discusses improving code quality in medical software through code reviews. It describes how one project implemented peer code reviews to prevent bugs, share knowledge, and improve discipline. The project evolved its workflow from long review cycles with many changes to immediate reviews of individual commits. Reviews check functionality, style, implementation, and readability. Commit messages are also reviewed to improve the project history. Tools like Git, Gerrit and Buildbot help automate version control, reviews and continuous integration.
Hardening Your CI/CD Pipelines with GitOps and Continuous Security
Join us for a webinar on how to secure your CI/CD pipeline for Kubernetes with GitOps best practices and continuous runtime protection. As modern developers and DevOps teams are embarking on a quest for speed and reliability through automated CI/CD pipelines for Kubernetes, enterprises still need to ensure security and regulatory compliance.
Together with Deepfence, the Weaveworks team will explain and demonstrate how GitOps continuous delivery pipelines, combined with continuous security observability, improves the overall security of your development workflow - from Git to production.
In this webinar we will demonstrate:
Deepfence container scanning
Git-to-Kubernetes using FluxCD
Deepfence continuous runtime security
1. Introduction
The document discusses the goals and challenges of software engineering. It notes that the goals of producing software that is correct, with minimal effort and cost, and in the least time are difficult to fully achieve. Large software involves many people and millions of dollars over many years. Real-life examples like Eclipse have over 1.35 million lines of code and cost over $54 million to develop. The document outlines why software engineering is important to avoid costly failures and ensure efficient development. It also discusses myths and the need for different approaches like formal processes for large software.
Similar to Icse2011 src (20)
Mining Co-Change Information to Understand when Build Changes are Necessary
Mining Co-Change Information to Understand when Build Changes are Necessary
Tracing Software Build Processes to Uncover License Compliance Inconsistencies
Tracing Software Build Processes to Uncover License Compliance Inconsistencies
Identifying Hotspots in the PostgreSQL Build Process
Identifying Hotspots in the PostgreSQL Build Process
Modern Release Engineering in a Nutshell - Why Researchers should Care!
Modern Release Engineering in a Nutshell - Why Researchers should Care!
Tracing Software Build Processes to Uncover License Compliance Inconsistencie...
Tracing Software Build Processes to Uncover License Compliance Inconsistencie...
BlackHat 2014 Briefings - Exploiting Fundamental Weaknesses in Botnet C&C Pan...
BlackHat 2014 Briefings - Exploiting Fundamental Weaknesses in Botnet C&C Pan...
An Empirical Analysis of Build Failures in the Continuous Integration Workflo...
An Empirical Analysis of Build Failures in the Continuous Integration Workflo...
Data Mining-based Tools to Support Library Update. PhD Defence of Oleksandr Z...
Data Mining-based Tools to Support Library Update. PhD Defence of Oleksandr Z...
Improving Code Quality In Medical Software Through Code Reviews - Vincit Teat...
Improving Code Quality In Medical Software Through Code Reviews - Vincit Teat...
Hardening Your CI/CD Pipelines with GitOps and Continuous Security
Hardening Your CI/CD Pipelines with GitOps and Continuous Security
More from SAIL_QU
Studying the Integration Practices and the Evolution of Ad Libraries in the G...
In-app advertisements have become a major revenue for app developers in the mobile app economy. Ad libraries play an integral part in this ecosystem as app
developers integrate these libraries into their apps to display ads. However, little is known about how app developers integrate these libraries with their apps and how these libraries have evolved over time.
In this thesis, we study the ad library integration practices and the evolution of such libraries. To understand the integration practices of ad libraries, we manually study apps and derive a set of rules to automatically identify four strategies for integrating
multiple ad libraries. We observe that integrating multiple ad libraries commonly occurs in apps with a large number of downloads and ones in categories with a high percentage of apps that display ads. We also observe that app developers prefer to manage their own integrations instead of using off the shelf features of ad libraries for integrating multiple ad libraries.
To study the evolution of ad libraries, we conduct a longitudinal study of the 8 most popular ad libraries. In particular, we look at their evolution in terms of size, the main drivers for releasing a new ad library version, and their architecture. We observe that ad libraries are continuously evolving with a median release interval of 34 days. Some ad libraries have grown exponentially in size (e.g., Facebook Audience Network ad library), while other libraries have worked to reduce their size. To study the main drivers for releasing an ad library version, we manually study the release notes of the eight studied ad libraries. We observe that ad library developers continuously update their ad libraries to support a wider range of Android versions (i.e., to ensure that more devices can use the libraries without errors). Finally, we derive a reference architecture for ad libraries and study how the studied ad libraries diverged from this architecture during our study period.
Our findings can assist ad library developers to understand the challenges for developing ad libraries and the desired features of these libraries.
Studying the Dialogue Between Users and Developers of Free Apps in the Google...
Presenting our paper "Studying the Dialogue Between Users and Developers of Free Apps in the Google Play Store" at ICSE 2018
Improving the testing efficiency of selenium-based load tests
Slides for a paper published at AST 2019:
Shahnaz M. Shariff, Heng Li, Cor-Paul Bezemer, Ahmed E. Hassan, Thanh H. D. Nguyen, and Parminder Flora. 2019. Improving the testing efficiency of selenium-based load tests. In Proceedings of the 14th International Workshop on Automation of Software Test (AST '19). IEEE Press, Piscataway, NJ, USA, 14-20. DOI: https://doi.org/10.1109/AST.2019.00008
Studying User-Developer Interactions Through the Distribution and Reviewing M...
This document discusses studying user-developer interactions through the distribution and reviewing mechanisms of the Google Play Store. It analyzes emergency updates made by developers to fix issues, the dialogue between users and developers through reviews and responses, and how the reviewing mechanism can help identify good and bad updates. The study found that responding to reviews is six times more likely to increase an app's rating, with 84% of rating increases going to four or five stars. Three common patterns of developer responses were identified: responding to negative or long reviews, only negative reviews, and reviews shortly after an update.
Studying online distribution platforms for games through the mining of data f...
Our studies of Steam platform data provided insights into online game distribution:
1) Urgent game updates were used to fix crashes, balance issues, and functionality; frequent updaters released more 0-day patches.
2) The Early Access model attracted indie developers and increased game participation; reviews were more positive during Early Access.
3) Game reviews were typically short and in English; sales increased review volume more than new updates; negative reviews came after longer play.
Understanding the Factors for Fast Answers in Technical Q&A Websites: An Empi...
This study analyzed factors that impact the speed of questions receiving accepted answers on four popular Stack Exchange websites: Stack Overflow, Mathematics, Ask Ubuntu, and Super User. The researchers examined question, answerer, asker, and answer factors from over 150,000 questions. They built classification models and found that key factors for fast answers included the past speed of answerers, length of the question, and past speed of answers for the question's tags. The models achieved AUCs of 0.85-0.95. Fast answers relied heavily on answerers, especially frequent answerers. The study suggests improving incentives for non-frequent and more difficult questions to attract diverse answerers.
Investigating the Challenges in Selenium Usage and Improving the Testing Effi...
Selenium is a popular tool for browser-based automation testing. The author analyzes challenges in using Selenium by mining Selenium questions on Stack Overflow. Programming language-related questions, especially for Java and Python, are most common and growing fastest. Less than half of questions receive accepted answers, and questions about browsers and components take longest. In the second part, the author develops an approach to improve efficiency of Selenium-based load testing by sharing browsers among user instances. This increases the number of error-free users by 20-22% while reducing memory usage.
Mining Development Knowledge to Understand and Support Software Logging Pract...
This document summarizes Heng Li's PhD thesis on mining development knowledge to understand and support software logging practices. It discusses how logging code is used to record runtime information but can be difficult for developers to maintain. The thesis aims to understand current logging practices and develop tools by mining change history, source code, issue reports, and other development knowledge. It presents research that analyzes logging-related issues to identify developers' logging concerns, uses code topics and structure to predict where logging statements should be added, leverages code changes to suggest when logging code needs updating, and applies machine learning models to recommend appropriate log levels.
Which Log Level Should Developers Choose For a New Logging Statement?
The document discusses choosing an appropriate log level when adding a new logging statement. It finds that an ordinal regression model can effectively model log levels, achieving an AUC of 0.76-0.81 in within-project evaluation and 0.71-0.8 in cross-project evaluation. The most influential factors for determining log levels vary between projects and include metrics related to the logging statement, containing code block, and file as well as code change and historical change metrics.
Towards Just-in-Time Suggestions for Log Changes
The document presents a study on providing just-in-time suggestions for log changes when developers make code changes. The researchers analyzed over 32,000 log changes from 4 systems. They found 20 reasons for log changes that fall into 4 categories: block changes, log improvements, dependence-driven changes, and logging issues. A random forest classifier using 25 software metrics related to code changes, history, and complexity achieved 0.84-0.91 AUC in predicting whether a log change is needed. Change metrics and product metrics were the most influential factors. The study aims to help developers make better logging decisions for failure diagnosis.
The Impact of Task Granularity on Co-evolution Analyses
The document discusses how task granularity at different levels (e.g. commits, pull requests, work items) can impact analyses of co-evolution in software projects. It finds that analyzing at the commit-level can overlook relationships between tasks that span multiple commits. Work item level analysis is recommended to provide a more complete view of co-evolution, as median of 29% of work items consist of multiple commits, and analyzing at the commit level would miss 24% of co-changed files and inability to group 83% of related commits.
A Framework for Evaluating the Results of the SZZ Approach for Identifying Bu...
Presented by Daniel da Costa, Shane McIntosh, Weiyi (Ian) Shang, Uira Kulesza, Roberta Coelho, and Ahmed E. Hassan
How are Discussions Associated with Bug Reworking? An Empirical Study on Open...
1) Initial bug fix discussions with more comments and more developers participating are more likely to experience later bug reworking through re-opening or re-patching of the bug.
2) Manual analysis found that defective initial fixes and failure to reach consensus in discussions contributed to later reworking.
3) For re-opened bugs, initial discussions focused on addressing a particular problem through a burst of comments, while re-patched bugs lacked thorough code review and testing during the initial fix period.
A Study of the Relation of Mobile Device Attributes with the User-Perceived Q...
This study examined the relationship between mobile device attributes and user-perceived quality of Android apps. The researchers analyzed 150,373 star ratings from Google Play across 30 devices and 280 apps. They found that the perceived quality of apps varies across devices, and having better characteristics of an attribute does not necessarily correlate with higher quality. Device OS version, resolution, and CPU showed significant relationships with ratings, as did some app attributes like lines of code and number of inputs. However, some device attributes had stronger relationships than app attributes.
A Large-Scale Study of the Impact of Feature Selection Techniques on Defect C...
This document presents the results of a large-scale study on the impact of feature selection techniques on defect classification models. The study used expanded scopes including multiple datasets from NASA and PROMISE with different feature types, more classification techniques from different paradigms, and additional feature selection techniques. The results show that correlation-based feature subset selection techniques like FS1 and FS2 consistently appear in the top ranks across most of the datasets, projects within the datasets, and classification techniques. The document concludes that future defect classification studies should consider applying correlation-based feature selection techniques.
Studying the Dialogue Between Users and Developers of Free Apps in the Google...
The study analyzes user-developer interactions through reviews and responses on the Google Play Store. It finds that responding to reviews has a significant positive impact, with 84% of rating increases due to the developer addressing the issue or providing guidance. Three common response patterns were identified: only negative reviews, negative or longer reviews, and reviews shortly after an update. Developers most often thank the user, ask for details, provide guidance, or ask for an endorsement. Guidance responses can address common issues through FAQs. The analysis considered over 2,000 apps, 355,000 review changes, 128,000 responses, and 4 million reviews.
What Do Programmers Know about Software Energy Consumption?
This document summarizes the results of a survey of 122 programmers about their knowledge of software energy consumption. The survey found that programmers have limited awareness of energy consumption and how to reduce it. They were unaware of the main causes of high energy usage. Programmers lacked knowledge about how to properly rank the energy consumption of different hardware components and were unfamiliar with strategies to improve efficiency, such as minimizing I/O and avoiding polling. The study concludes that programmers would benefit from more education on software energy usage and its causes.
Threshold for Size and Complexity Metrics: A Case Study from the Perspective ...
Presented by Kazuhiro Yamashita, Changyun Huang, Meiyappan Nagappan, Yasutaka Kamei, Audris Mockus, Ahmed E. Hassan, and Naoyasu Ubayashi
Revisiting the Experimental Design Choices for Approaches for the Automated R...
Prior research on automated duplicate issue report retrieval focused on improving performance metrics like recall rate. The author revisits experimental design choices from four perspectives: needed effort, data changes, data filtration, and evaluation process.
The thesis contributions are: 1) Showing the importance of considering needed effort in performance measurement. 2) Proposing a "realistic evaluation" approach and analyzing prior findings with it. 3) Developing a genetic algorithm to filter old issue reports and improve performance. 4) Highlighting the impact of "just-in-time" features on evaluation. The findings help better understand benefits and limitations of prior work in this area.
Measuring Program Comprehension: A Large-Scale Field Study with Professionals
The document summarizes a large-scale field study that tracked the program comprehension activities of 78 professional developers over 3,148 hours. The study found that:
1) Program comprehension accounted for approximately 58% of developers' time on average, with navigation and editing making up the remaining portions.
2) Developers frequently used web browsers and document editors to aid comprehension beyond just IDEs.
3) Interviews and observations revealed that insufficient documentation, unclear code, and complex inheritance hierarchies contributed to long comprehension sessions.
More from SAIL_QU (20)
Studying the Integration Practices and the Evolution of Ad Libraries in the G...
Studying the Integration Practices and the Evolution of Ad Libraries in the G...
Studying the Dialogue Between Users and Developers of Free Apps in the Google...
Studying the Dialogue Between Users and Developers of Free Apps in the Google...
Improving the testing efficiency of selenium-based load tests
Improving the testing efficiency of selenium-based load tests
Studying User-Developer Interactions Through the Distribution and Reviewing M...
Studying User-Developer Interactions Through the Distribution and Reviewing M...
Studying online distribution platforms for games through the mining of data f...
Studying online distribution platforms for games through the mining of data f...
Understanding the Factors for Fast Answers in Technical Q&A Websites: An Empi...
Understanding the Factors for Fast Answers in Technical Q&A Websites: An Empi...
Investigating the Challenges in Selenium Usage and Improving the Testing Effi...
Investigating the Challenges in Selenium Usage and Improving the Testing Effi...
Mining Development Knowledge to Understand and Support Software Logging Pract...
Mining Development Knowledge to Understand and Support Software Logging Pract...
Which Log Level Should Developers Choose For a New Logging Statement?
Which Log Level Should Developers Choose For a New Logging Statement?
The Impact of Task Granularity on Co-evolution Analyses
The Impact of Task Granularity on Co-evolution Analyses
A Framework for Evaluating the Results of the SZZ Approach for Identifying Bu...
A Framework for Evaluating the Results of the SZZ Approach for Identifying Bu...
How are Discussions Associated with Bug Reworking? An Empirical Study on Open...
How are Discussions Associated with Bug Reworking? An Empirical Study on Open...
A Study of the Relation of Mobile Device Attributes with the User-Perceived Q...
A Study of the Relation of Mobile Device Attributes with the User-Perceived Q...
A Large-Scale Study of the Impact of Feature Selection Techniques on Defect C...
A Large-Scale Study of the Impact of Feature Selection Techniques on Defect C...
Studying the Dialogue Between Users and Developers of Free Apps in the Google...
Studying the Dialogue Between Users and Developers of Free Apps in the Google...
What Do Programmers Know about Software Energy Consumption?
What Do Programmers Know about Software Energy Consumption?
Threshold for Size and Complexity Metrics: A Case Study from the Perspective ...
Threshold for Size and Complexity Metrics: A Case Study from the Perspective ...
Revisiting the Experimental Design Choices for Approaches for the Automated R...
Revisiting the Experimental Design Choices for Approaches for the Automated R...
Measuring Program Comprehension: A Large-Scale Field Study with Professionals
Measuring Program Comprehension: A Large-Scale Field Study with Professionals
Icse2011 src
- 1. Build System Maintenance Shane McIntosh
- 2. What is the build system? 2 .c .c
- 3. What is the build system? 2 .c.c .o .o .exe
- 4. Build code is complex... 3
- 5. Build Maintenance is a Nuisance for Developers 4
- 6. Build Maintenance is a Nuisance for Developers 4
- 7. Build Maintenance is a Nuisance for Developers 4 Autotools Make
- 8. Build Maintenance is a Nuisance for Developers 4 Autotools Make Migration to newer build technology
- 9. 5 Build Bugs Even Affect the End User!
- 10. Address Bar 5 Build Bugs Even Affect the End User!
- 11. Address Bar Search Bar 5 Build Bugs Even Affect the End User!
- 12. Address Bar Search Bar 5 Build Bugs Even Affect the End User!
- 13. Address Bar Search Bar 5 Build Bugs Even Affect the End User!
- 14. Build Systems Require 12% of a Developer’s Time (on average) 6 Kumfert, G., and Epperly,T. Software in the DOE: The Hidden Overhead of the “Build”
- 15. Build Systems Require 12% of a Developer’s Time (on average) 6 Kumfert, G., and Epperly,T. Software in the DOE: The Hidden Overhead of the “Build” Build maintenance slows development!
- 16. 7 Size Evolution Coupling People Four Dimensional Study of Build Maintenance .mk?.c
- 17. 8
- 18. 8 PLplot
- 19. 9 PLplot .mk?.c Size 9% of all files Evolution Coupling Tightly coupled People Dispersed or concentrated Build churn >> src churn
- 20. 10 PLplot .mk?.c Size 9% of all files Evolution Coupling Tightly coupled People Dispersed or concentrated Build churn >> src churn
- 21. Identifying build maintainers .c .c .c .ac.c Source Build .c .c
- 22. Identifying build maintainers Change list #1 .c .c .c Change list #3 Change list #4 .ac.c Change list #2 Source Build .c .c
- 23. Identifying build maintainers Change list #1 .c .c .c Change list #3 Change list #4 .ac.c Change list #2 25% build Source Build .c .c
- 24. Identifying build maintainers Change list #1 .c .c .c Change list #3 Change list #4 .ac.c Change list #2 25% build Source Build .c .c
- 25. Identifying build maintainers Change list #1 .c .c .c Change list #3 Change list #4 .ac.c Change list #2 0% build 25% build Source Build .c .c
- 26. Identifying build maintainers Change list #1 .c .c .c Change list #3 Change list #4 .ac.c Change list #2 0% build 25% build Source Build .c .c
- 27. Identifying build maintainers Change list #1 .c .c .c Change list #3 Change list #4 .ac.c Change list #2 0% build 50% build 25% build Source Build .c .c
- 28. Identifying build maintainers Change list #1 .c .c .c Change list #3 Change list #4 .ac.c Change list #2 0% build 50% build Source Build .c .c ≥
- 29. Identifying build maintainers Change list #1 .c .c .c Change list #3 Change list #4 .ac.c Change list #2 0% build 50% build Source Build .c .c ≥
- 30. If you maintain source code, do you maintain build code? 12 25%22% 79% % of developers
- 31. If you maintain source code, do you maintain build code? 12 25%22% 79% % of developers
- 32. Dispersed Ownership: Build maintenance is distributed amongst most team members 13
- 33. Dispersed Ownership: Build maintenance is distributed amongst most team members 13 Concentrated Ownership: A small team is responsible for most of the build maintenance
- 34. Dispersed Ownership: Build maintenance is distributed amongst most team members 13 Concentrated Ownership: A small team is responsible for most of the build maintenance Which build ownership style performs best?
- 35. Tool Support Needed for Build Maintenance! 14 Build churn >> source churn Build maintenance required for 27% of source code tasks
- 36. 15 PLplot .mk?.c Size 9% of all files Evolution Coupling Tightly coupled People Dispersed or concentrated Build churn >> src churn
- 37. 15 PLplot .mk?.c Size 9% of all files Evolution Coupling Tightly coupled People Dispersed or concentrated Build churn >> src churn Questions?