DOCSLIB.ORG

Tackling Build Failures in Continuous Integration

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Tackling Build Failures in Continuous Integration TACKLING BUILD FAILURES IN CONTINUOUS INTEGRATION by FOYZUL HASSAN, M.Sc. DISSERTATION Presented to the Graduate Faculty of The University of Texas at San Antonio In Partial Fulfillment Of the Requirements For the Degree of DOCTOR OF PHILOSOPHY IN COMPUTER SCIENCE COMMITTEE MEMBERS: Xiaoyin Wang, Ph.D., Chair Jianwei Niu, Ph.D. Wei Wang, Ph.D. Palden Lama, Ph.D. Lingming Zhang, Ph.D. THE UNIVERSITY OF TEXAS AT SAN ANTONIO College of Sciences Department of Computer Science May 2020 ProQuest Number:27957408 All rights reserved INFORMATION TO ALL USERS The quality of this reproduction is dependent on the quality of the copy submitted. In the unlikely event that the author did not send a complete manuscript and there are missing pages, these will be noted. Also, if material had to be removed, a note will indicate the deletion. ProQuest 27957408 Published by ProQuest LLC (2020). Copyright of the Dissertation is held by the Author. All Rights Reserved. This work is protected against unauthorized copying under Title 17, United States Code Microform Edition © ProQuest LLC. ProQuest LLC 789 East Eisenhower Parkway P.O. Box 1346 Ann Arbor, MI 48106 - 1346 Copyright 2020 Foyzul Hassan All rights reserved. DEDICATION To my parents To my wife Fariha To rest of my family ACKNOWLEDGEMENTS First of all, I would like to thank my adviser, Dr. Xiaoyin Wang. Without his guidance, sup- port, and assistance, it would not be possible for me to finish my dissertation. I very much enjoyed spending time and working with him. Dr. Wang always helped in identifying, formulating, and solving research problems, and patiently advised the publications and presentations to improve the quality of my research results. Apart from research work, his advises on professional career paths and preparation for professional carrier have been invaluable. Besides my advisor, I would like to thank the rest of my dissertation committee: Prof. Jianwei Niu, Prof. Palden Lama, Prof. Wei Wang and Prof. Lingming Zhang for their support, insightful comments, constructive feedback, and challenging questions. I am thankful to Prof. Na Meng from Virginia Tech for being a great collaborator and imparting her knowledge of fault-localization techniques. I am also grateful to my research internship mentors at Microsoft Research Nachi Nagappan, Tom Zimmermann, Chetan Bansal and Ahmed Hassan Awadallah for their guidance and fruitful discussion on identifying new research problems. I am privileged to be associated with the current software engineering group at UTSA and like to thank my fellow lab mates: Shaikh Nahid Mostafa, and Xue Qin. Without your great and enjoy- able company, it was not possible for me to pass the long journey here. My sincerest gratitude and appreciation go to my lovely wife Fariha Nusrat for constantly sup- porting me and going through hardships during my PhD years. I would also like to thank my parents, my brother and my sister for their never-ending love, care, and support. Finally, I would like to thank the financial support provided by the Department of Com- puter Science at UTSA, as well as the funding support from the National Science Foundation (Grant:1464425,1846467). iv This Masters Thesis/Recital Document or Doctoral Dissertation was produced in accordance with guidelines which permit the inclusion as part of the Masters Thesis/Recital Document or Doc- toral Dissertation the text of an original paper, or papers, submitted for publication. The Masters Thesis/Recital Document or Doctoral Dissertation must still conform to all other requirements explained in the Guide for the Preparation of a Masters Thesis/Recital Document or Doctoral Dis- sertation at The University of Texas at San Antonio. It must include a comprehensive abstract, a full introduction and literature review, and a final overall conclusion. Additional material (proce- dural and design data as well as descriptions of equipment) must be provided in sufficient detail to allow a clear and precise judgment to be made of the importance and originality of the research reported. It is acceptable for this Masters Thesis/Recital Document or Doctoral Dissertation to include as chapters authentic copies of papers already published, provided these meet type size, margin, and legibility requirements. In such cases, connecting texts, which provide logical bridges between different manuscripts, are mandatory. Where the student is not the sole author of a manuscript, the student is required to make an explicit statement in the introductory material to that manuscript describing the students contribution to the work and acknowledging the contribution of the other author(s). The signatures of the Supervising Committee which precede all other material in the Masters Thesis/Recital Document or Doctoral Dissertation attest to the accuracy of this statement. May 2020 v TACKLING BUILD FAILURES IN CONTINUOUS INTEGRATION Foyzul Hassan, Ph.D. The University of Texas at San Antonio, 2020 Supervising Professor: Xiaoyin Wang, Ph.D. In popular continuous integration(CI) practice, coding is followed by building, integration and system testing, pre-release inspection and deploying artifacts. This can reduce integration time and speed up the development process. At CI environment, dedicated infrastructure with different build systems such as Make, Ant, Maven, Gradle, Bazel, etc. are used to automate CI tasks like compilation, test invocation, etc. For continuous integration, developers describe build process though build scripts such as build.xml for Ant, pom.xml for Maven, and build.gradle for Gradle. But with the growing functionality and CI requirement, build scripts can very complex and may require frequent maintenance. Meanwhile, a large number of continuous integration failures may interrupt normal software development so that they need to be repaired as soon as possible. According to the TravisTorrent dataset of open-source software continuous integration, 22% of code commits include changes in build script files to maintain build scripts or to resolve CI failures. CI failures bring both challenges and opportunities to fault localization and program repair techniques. On the challenge side, unlike traditional fault localization scenarios (e.g., unit testing, regression testing) where only source code needs to be considered, CI failures can also be caused by build configuration errors and environment changes. Actually, the CI practice has make it a necessity for developers to automate the software build process with build scripts and configuration files. As a result, the build maintenance needs a substantial amount of developer efforts, and developer’s carelessness may lead to defects in build scripts also. On the opportunity side, the scenario of continuous integration provides rich code commit history and build logs from previous passing builds and current failing builds. Such information sources are often not available in other application scenarios. Taking advantage of these additional vi information sources, we may be able to further improve the accuracy of automatic repair and fault localization for CI failures. Automated program repair techniques have great potential to reduce the cost of resolving soft- ware failures, but the existing techniques mostly focus on repairing source code so that they cannot directly help resolving software CI failures. To address this limitation, we proposed the first ap- proach to automatic patch generation for build scripts, using fix patterns automatically generated from existing build script fixes and recommending fix patterns based on build log similarity. Apart from build script, CI failures are often a combination of test failures and build failures, and sometimes both source code and various build scripts need to be touched in the repair of one failure. To address this issue, we proposed a unified technique to localize faults in both source code and build scripts given CI failures. Adopting the information retrieval (IR) strategy, UniLoc locates buggy files by treating source code and build scripts as documents to search, and by considering build logs as search queries. However, instead of naively applying an off-the-shelf IR technique to these software artifacts, for more accurate fault localization, UniLoc (Unified Fault Localiza- tion) applies various domain-specific heuristics to optimize the search queries, search space, and ranking formulas. However, UniLoc can localize faults up to file level and limited to find faults in source code and build scripts. In the future, we are planning to expand our fault localization approach to the source code and build script block level to assist developers and automatic repair approaches better. Finally, beyond source code and build scripts, there are also other types of files to be involved during software repair, especially in other scenarios. For example, in the fault locali- zation of web applications, we need to consider Html files, css files, client-side JavaScript files and server side source code. We plan to adapt our technique to more scenarios with heterogeneous bug locations. Proposed CI fault localization technique with program repair can be a handy solution to fix a range of CI failures. vii TABLE OF CONTENTS Acknowledgements . iv Abstract . vi List of Tables . xiii List of Figures . xv Chapter 1: Introduction . 1 1.1 Motivation . .1 1.2 Thesis Statement . .4 1.3 Contributions . .4 1.4 Organization . .6 Chapter 2: Background and Related Work . 7 2.1 Analysis of Build Configuration Files . .7 2.1.1 Automatic Program Repair . .8 2.2 Automatic Fault Localization . .9 2.3 Containerized Software Development . 10 Chapter 3: Automatic Building of Java Projects in Software Repositories: A Study on Feasibility and Challenges . 12 3.1 Introduction . 12 3.2 Study Design . 15 3.2.1 Research Questions . 15 3.2.2 Study Setup . 15 3.3 Study on Successfulness of Default Build Commands (RQ1)............ 16 3.4 A Taxonomy of Root Causes of Build Failures (RQ2)................ 17 viii 3.4.1 Environment Issues . 18 3.4.2 Process Issues . 21 3.4.3 Project Issues . 22 3.5 Identifying Root Causes of Build Failures (RQ3).................
Load more

Recommended publications
  • SIGSOFT CFP-ICSE04.Qxd
    General Chair Richard N. Taylor Call for Participation University of California, Irvine [email protected] ACM SIGSOFT 2004 Program Chair Matthew B. Dwyer Twelfth International Symposium on the Kansas State University Foundations of Software Engineering FSE-12 [email protected] Newport Beach Program Committee Ken Anderson, U Colorado, Boulder, USA October 31 - November 5, 2004 Annie Antón, North Carolina State U, USA Hyatt Newporter Hotel, Newport Beach, California, USA Joanne Atlee, U Waterloo, Canada Prem Devanbu, U California, Davis, USA http://www.isr.uci.edu/FSE-12/ Mary Jean Harrold, Georgia Tech, USA John Hatcliff, Kansas State U, USA Jim Herbsleb, Carnegie Mellon U, USA SIGSOFT 2004 brings together researchers and practitioners from academia and industry to André van der Hoek, U California, Irvine, exchange new results related to both traditional and emerging fields of software engineer- USA ing. SIGSOFT 2004 will feature four workshops, one day of tutorials organized through the Paola Inverardi, U L'Aquila, Italy Educator's Grant Program (EGP), a student resarch forum with posters, along with FSE-12. Gregor Kiczales, U British Columbia, Canada Jeff Kramer, Imperial College London, UK FSE-12 will be held Tuesday-Thursday, November 2-4. We are pleased to announce the Shriram Krishnamurthi, Brown U, USA keynotes: Shinji Kusumoto, Osaka U, Japan Axel van Lamsweerde, U Catholique de Alexander L. Wolf, University of Colorado at Boulder, Tues. Nov. 2 Louvain, Belgium Bashar Nuseibeh, The Open U, UK Joe Marks, Director, Mitsubishi Electric Research Laboratories, Cambridge, Wed. Nov. 3 Mauro Pezzé, U Milano-Bicocca, Italy SIGSOFT Distinguished Research Award winner, Thur.
    [Show full text]
  • Poly Videoos Offer of Source for Open Source Software 3.6.0
    OFFER OF SOURCE FOR 3.6.0 | 2021 | 3725-85857-010A OPEN SOURCE SOFTWARE August Poly VideoOS Software Contents Offer of Source for Open Source Software .............................................................................. 1 Open Source Software ............................................................................................................. 2 Qualcomm Platform Licenses ............................................................................................................. 2 List of Open Source Software .................................................................................................. 2 Poly G7500, Poly Studio X50, and Poly Studio X30 .......................................................................... 2 Poly Microphone IP Adapter ............................................................................................................. 13 Poly IP Table Microphone and Poly IP Ceiling Microphone ............................................................. 18 Poly TC8 and Poly Control Application ............................................................................................. 21 Get Help ..................................................................................................................................... 22 Related Poly and Partner Resources ..................................................................................... 22 Privacy Policy ...........................................................................................................................
    [Show full text]
  • A Comprehensive Study of Bloated Dependencies in the Maven Ecosystem
    Noname manuscript No. (will be inserted by the editor) A Comprehensive Study of Bloated Dependencies in the Maven Ecosystem César Soto-Valero · Nicolas Harrand · Martin Monperrus · Benoit Baudry Received: date / Accepted: date Abstract Build automation tools and package managers have a profound influence on software development. They facilitate the reuse of third-party libraries, support a clear separation between the application’s code and its ex- ternal dependencies, and automate several software development tasks. How- ever, the wide adoption of these tools introduces new challenges related to dependency management. In this paper, we propose an original study of one such challenge: the emergence of bloated dependencies. Bloated dependencies are libraries that the build tool packages with the application’s compiled code but that are actually not necessary to build and run the application. This phenomenon artificially grows the size of the built binary and increases maintenance effort. We propose a tool, called DepClean, to analyze the presence of bloated dependencies in Maven artifacts. We ana- lyze 9; 639 Java artifacts hosted on Maven Central, which include a total of 723; 444 dependency relationships. Our key result is that 75:1% of the analyzed dependency relationships are bloated. In other words, it is feasible to reduce the number of dependencies of Maven artifacts up to 1=4 of its current count. We also perform a qualitative study with 30 notable open-source projects. Our results indicate that developers pay attention to their dependencies and are willing to remove bloated dependencies: 18/21 answered pull requests were accepted and merged by developers, removing 131 dependencies in total.
    [Show full text]
  • Seisio: a Fast, Efficient Geophysical Data Architecture for the Julia
    1 SeisIO: a fast, efficient geophysical data architecture for 2 the Julia language 1∗ 2 2 2 3 Joshua P. Jones , Kurama Okubo , Tim Clements , and Marine A. Denolle 1 4 4509 NE Sumner St., Portland, OR, USA 2 5 Department of Earth and Planetary Sciences, Harvard University, MA, USA ∗ 6 Corresponding author: Joshua P. Jones ([email protected]) 1 7 Abstract 8 SeisIO for the Julia language is a new geophysical data framework that combines the intuitive 9 syntax of a high-level language with performance comparable to FORTRAN or C. Benchmark 10 comparisons with recent versions of popular programs for seismic data download and analysis 11 demonstrate significant improvements in file read speed and orders-of-magnitude improvements 12 in memory overhead. Because the Julia language natively supports parallel computing with an 13 intuitive syntax, we benchmark test parallel download and processing of multi-week segments of 14 contiguous data from two sets of 10 broadband seismic stations, and find that SeisIO outperforms 15 two popular Python-based tools for data downloads. The current capabilities of SeisIO include file 16 read support for several geophysical data formats, online data access using FDSN web services, 17 IRIS web services, and SeisComP SeedLink, with optimized versions of several common data 18 processing operations. Tutorial notebooks and extensive documentation are available to improve 19 the user experience (UX). As an accessible example of performant scientific computing for the 20 next generation of researchers, SeisIO offers ease of use and rapid learning without sacrificing 21 computational performance. 2 22 1 Introduction 23 The dramatic growth in the volume of collected geophysical data has the potential to lead to 24 tremendous advances in the science (https://ds.iris.edu/data/distribution/).
    [Show full text]
  • Gateway Licensing Information User Manual Version 19
    Gateway Licensing Information User Manual Version 19 December 2019 Contents Introduction ...................................................................................................................................... 5 Licensed Products, Restricted Use Licenses, and Prerequisite Products ........................................ 5 Primavera Gateway ................................................................................................................................ 5 Third Party Notices and/or Licenses ................................................................................................ 6 Bootstrap ................................................................................................................................................ 6 Commons Codec .................................................................................................................................... 6 Commons Compress .............................................................................................................................. 6 Commons IO ........................................................................................................................................... 7 Commons Net ......................................................................................................................................... 7 commons-vfs .......................................................................................................................................... 7 HttpComponents HttpClient ..................................................................................................................
    [Show full text]
  • Empirical Study of Restarted and Flaky Builds on Travis CI
    Empirical Study of Restarted and Flaky Builds on Travis CI Thomas Durieux Claire Le Goues INESC-ID and IST, University of Lisbon, Portugal Carnegie Mellon University [email protected] [email protected] Michael Hilton Rui Abreu Carnegie Mellon University INESC-ID and IST, University of Lisbon, Portugal [email protected] [email protected] ABSTRACT Continuous integration is an automatic process that typically Continuous Integration (CI) is a development practice where devel- executes the test suite, may further analyze code quality using static opers frequently integrate code into a common codebase. After the analyzers, and can automatically deploy new software versions. code is integrated, the CI server runs a test suite and other tools to It is generally triggered for each new software change, or at a produce a set of reports (e.g., the output of linters and tests). If the regular interval, such as daily. When a CI build fails, the developer is result of a CI test run is unexpected, developers have the option notified, and they typically debug the failing build. Once the reason to manually restart the build, re-running the same test suite on for failure is identified, the developer can address the problem, the same code; this can reveal build flakiness, if the restarted build generally by modifying or revoking the code changes that triggered outcome differs from the original build. the CI process in the first place. In this study, we analyze restarted builds, flaky builds, and their However, there are situations in which the CI outcome is unex- impact on the development workflow.
    [Show full text]
  • Evil Pickles: Dos Attacks Based on Object-Graph Engineering∗
    Evil Pickles: DoS Attacks Based on Object-Graph Engineering∗ Jens Dietrich1, Kamil Jezek2, Shawn Rasheed3, Amjed Tahir4, and Alex Potanin5 1 School of Engineering and Advanced Technology, Massey University Palmerston North, New Zealand [email protected] 2 NTIS – New Technologies for the Information Society Faculty of Applied Sciences, University of West Bohemia Pilsen, Czech Republic [email protected] 3 School of Engineering and Advanced Technology, Massey University Palmerston North, New Zealand [email protected] 4 School of Engineering and Advanced Technology, Massey University Palmerston North, New Zealand [email protected] 5 School of Engineering and Computer Science Victoria University of Wellington, Wellington, New Zealand [email protected] Abstract In recent years, multiple vulnerabilities exploiting the serialisation APIs of various programming languages, including Java, have been discovered. These vulnerabilities can be used to devise in- jection attacks, exploiting the presence of dynamic programming language features like reflection or dynamic proxies. In this paper, we investigate a new type of serialisation-related vulnerabilit- ies for Java that exploit the topology of object graphs constructed from classes of the standard library in a way that deserialisation leads to resource exhaustion, facilitating denial of service attacks. We analyse three such vulnerabilities that can be exploited to exhaust stack memory, heap memory and CPU time. We discuss the language and library design features that enable these vulnerabilities, and investigate whether these vulnerabilities can be ported to C#, Java- Script and Ruby. We present two case studies that demonstrate how the vulnerabilities can be used in attacks on two widely used servers, Jenkins deployed on Tomcat and JBoss.
    [Show full text]
  • Executable Trigger-Action Comments
    Executable Trigger-Action Comments Pengyu Nie, Rishabh Rai, Junyi Jessy Li, Sarfraz Khurshid, Raymond J. Mooney, and Milos Gligoric The University of Texas at Austin {pynie@,rrai.squared@,jessy@austin.,khurshid@ece.,mooney@cs.,gligoric@}utexas.edu ABSTRACT Wave project: “Remove this when HtmlViewImpl implements getAt- Natural language elements, e.g., todo comments, are frequently tributes”, etc.). We consider those comments where the trigger is used to communicate among the developers and to describe tasks expressed based on the state of the code repositories and actions that need to be performed (actions) when specific conditions hold require modifications of source or binary code. We call these com- in the code repository (triggers). As projects evolve, development ments trigger-action comments. processes change, and development teams reorganize, these com- Although trigger-action comments are ubiquitous, they are, like ments, because of their informal nature, frequently become irrele- other types of comments, written in natural language. Thus, as vant or forgotten. projects evolve, development processes change, and development We present the first technique, dubbed TrigIt, to specify trigger- teams reorganize, these comments frequently become irrelevant or action todo comments as executable statements. Thus, actions are forgotten. As an example, consider the following comment from executed automatically when triggers evaluate to true. TrigIt spec- the Apache Gobblin project [13]: “Remove once we commit any ifications are written in the host language (e.g., Java) and are evalu- other classes”. This comment, followed by an empty class, was in- ated as part of the build process. The triggers are specified as query cluded in revision 38ce024 (Dec 10, 2015) in package-info.java file statements over abstract syntax trees and abstract representation to force the javadoc tool to generate documentation for an empty of build configuration scripts, and the actions are specified as code package.
    [Show full text]
  • Devops Point of View an Enterprise Architecture Perspective
    DevOps Point of View An Enterprise Architecture perspective Amsterdam, 2020 Management summary “It is not the strongest of the species that survive, nor the most intelligent, but the one most responsive to change.”1 Setting the scene Goal of this Point of View In the current world of IT and the development of This point of view aims to create awareness around the IT-related products or services, companies from transformation towards the DevOps way of working, to enterprise level to smaller sizes are starting to help gain understanding what DevOps is, why you need it use the DevOps processes and methods as a part and what is needed to implement DevOps. of their day-to-day organization process. The goal is to reduce the time involved in all the An Enterprise Architecture perspective software development phases, to achieve greater Even though it is DevOps from an Enterprise Architecture application stability and faster development service line perspective, this material has been gathered cycles. from our experiences with customers, combined with However not only on the technical side of the knowledge from subject matter experts and theory from organization is DevOps changing the playing within and outside Deloitte. field, also an organizational change that involves merging development and operations teams is Targeted audience required with an hint of cultural changes. And last but not least the skillset of all people It is specifically for the people within Deloitte that want to involved is changing. use this as an accelerator for conversations and proposals & to get in contact with the people who have performed these type of projects.
    [Show full text]
  • Usage, Costs, and Benefits of Continuous Integration in Open
    Usage, Costs, and Benefits of Continuous Integration in Open-Source Projects Michael Hilton Timothy Tunnell Kai Huang Oregon State University University of Illinois at University of Illinois at [email protected] Urbana-Champaign Urbana-Champaign [email protected] [email protected] Darko Marinov Danny Dig University of Illinois at Oregon State University Urbana-Champaign [email protected] [email protected] ABSTRACT CI using several quality metrics. However, the study does Continuous integration (CI) systems automate the compi- not present any detailed information about the use of CI. lation, building, and testing of software. Despite CI rising In fact, despite some folkloric evidence about the use of CI, as a big success story in automated software engineering, it there is no systematic study about CI systems. has received almost no attention from the research commu- Not only do we lack basic knowledge about the extent nity. For example, how widely is CI used in practice, and to which open-source projects are adopting CI, but also what are some costs and benefits associated with CI? With- we have no answers to many other important questions re- out answering such questions, developers, tool builders, and lated to CI. What are the costs of CI? Does CI deliver researchers make decisions based on folklore instead of data. on the promised benefits, such as releasing more often, or In this paper, we use three complementary methods to helping make changes (e.g., to merge pull requests) faster? study in-depth the usage of CI in open-source projects. To Are developers maximizing the usage of CI? Despite the understand what CI systems developers use, we analyzed widespread popularity of CI, we have very little quantita- 34,544 open-source projects from GitHub.
    [Show full text]
  • Improving Web Services Maintenance Through Regression Testing Divya Rohatgi, Prof
    Volume 3, Issue 5, May-2016, pp. 261-265 ISSN (O): 2349-7084 International Journal of Computer Engineering In Research Trends Available online at: www.ijcert.org Improving Web Services Maintenance through Regression Testing Divya Rohatgi, Prof. (Col) Gurmit Singh 1. Research Scholar, Computer Science and Engineering Department Sam Higginbottom Institute of Agriculture, Technology and Sciences Deemed University, Allahabad, India 2. Professor, Computer Science and Engineering Department Sam Higginbottom Institute of Agriculture, Technology and Sciences Deemed University, Allahabad, India Abstract: - Software maintenance is considered to be the most expensive activity in software development and is used to ensure quality to the product. Regression Testing is a part of software maintainers which is done every time the software is changed. For software like Web services which represent a class of Service oriented architectures this activity is a challenging task. Since web services incorporate business functionality thus maintaining proper quality is an important concern. Due to inherent distributed, heterogeneous and dynamic in nature, regression testing is difficult and time consuming activity. Thus in order to reduce maintenance cost we have to reduce regression testing cost. Thus in this paper, we have given a comprehensive study of regression testing of web services exploring the challenges, approaches and tools used for them to ensure proper quality and inherently reducing the maintenance costs. Keywords – Software Engineering, Software Maintenance, Regression Testing, Web Service. —————————— —————————— 1. INTRODUCTION implications deriving from the adoption of the standardized stack of technology underlying web In today’s growing and competitive scenario Service– services (e.g., SOAP, WSDL, UDDI, etc.); oriented architectures are having a crucial role in the way in which systems are developed and designed.
    [Show full text]
  • FINAL PROGRAM University of California, Irvine [email protected] Program Chair Matthew B
    General Chair Richard N. Taylor FINAL PROGRAM University of California, Irvine [email protected] Program Chair Matthew B. Dwyer ACM SIGSOFT 2004 University of Nebraska-Lincoln [email protected] Twelfth International Symposium on the Program Committee Ken Anderson, U Colorado, Boulder, USA Foundations of Software Engineering FSE-12 Annie Antón, North Carolina State U, USA Joanne Atlee, U Waterloo, Canada Prem Devanbu, U California, Davis, USA Mary Jean Harrold, Georgia Tech, USA John Hatcliff, Kansas State U, USA Jim Herbsleb, Carnegie Mellon U, USA André van der Hoek, U Calif., Irvine, USA Paola Inverardi, U L'Aquila, Italy Gregor Kiczales, U British Columbia, Canada Jeff Kramer, Imperial College London, UK Shriram Krishnamurthi, Brown U, USA Shinji Kusumoto, Osaka U, Japan Axel van Lamsweerde, U Catholique de Louvain, Belgium Bashar Nuseibeh, The Open U, UK Mauro Pezzé, U Milano-Bicocca, Italy Gian Pietro Picco, Politecnico di Milano, Italy David Rosenblum, U College London, UK Gregg Rothermel, U Nebraska-Lincoln, USA Wilhelm Schäfer, U Paderborn, Germany Douglas Schmidt, Vanderbilt U, USA Peri Tarr, IBM T.J. Watson, USA Frank Tip, IBM T.J. Watson, USA Willem C. Visser, NASA Ames, USA http://www.isr.uci.edu/FSE-12/ Student and Diversity Programs Co-Chairs October 31 - November 5, 2004 Educators Grant Program and Tutorials Hyatt Newporter Hotel, Newport Beach, California, USA Mary Jean Harrold Georgia Tech [email protected] Mary Lou Soffa SIGSOFT 2004 brings together researchers and practitioners from academia and industry to University of Virginia exchange new results related to both traditional and emerging fields of software engineering.
    [Show full text]