When releasing system updates, software engineers often desire existing users to migrate to the updated system. Our experience has been that migration difficulty scales with the difference in functionality between the old system and the new system. If this difference is sufficiently large, the migration task becomes prohibitively difficult for existing consumers. To better incentivize migration, system authors should prioritize providing an incremental migration path to the new system, reducing migration cost and thus improving migration rate. Research efforts should focus on "patterns of incrementality" to assist system designers.

When a new set of types is introduced into a large software system, the task of retrofitting that system to take advantage of those types is generally cost-prohibitive. Existing automated type migration systems assume a one-to-one correspondence between old types and new types, making them unable to do partial migrations to more complex type sets. By using compiler-based migration tooling and an algebraically modeled type set, it is possible to use a small amount of manually seeded type information to automatically propagate the new types through a large monolithic C++ codebase. We demonstrate this technique by automatically generating 20k+ individual changes across a large industrial codebase of millions of lines of C++.

Maintaining large code bases can be a challenging endeavour. As new libraries, APIs and standards are introduced, old code is migrated to use them. To provide as clean and succinct an interface as possible for developers, old APIs are ideally removed as new ones are introduced. In practice, this becomes difficult as automatically finding and transforming code in a semantically correct way can be challenging, particularly as the size of a code base increases. In this paper, we present a real-world implementation of a system to refactor large C++ code bases efficiently. A combination of the Clang compiler framework and the MapReduce parallel processor, ClangMR enables code maintainers to easily and correctly transform large collections of code. We describe the motivation behind such a tool, its implementation and then present our experiences using it in a recent API update with Google's C++ code base.

The release and deployment phase of the software development process is often overlooked as part of broader software engineering research. In this paper, we discuss early results from a set of multiple semi-structured interviews with practicing release engineers. Subjects for the interviews are drawn from a number of different commercial software development organizations, and our interviews focus on why release process faults and failures occur, how organizations recover from them, and how they can be predicted, avoided or prevented in the future. Along the way, the interviews provide insight into the state of release engineering today, and interesting relationships between software architecture and release processes.

Software releases form a critical part of the life cycle of a software project. Typically, each project produces releases in its own way, using various methods of versioning, archiving, announcing and publishing the release. Understanding the release history of a software project can shed light on the project history, as well as the release process used by that project, and how those processes change. However, many factors make automating the retrieval of release history information difficult, such as the many sources of data, a lack of relevant standards and a disparity of tools used to create releases.

Increasingly wireless networks use multi-antenna nodes as in IEEE 802.11n and 802.16. The physical layer (PHY) in such systems may use the antennas to provide multiple streams of data (spatial multiplexing) or to increase the robustness of fewer streams. These physical layers also provide support for sending packets at different rates by changing the modulation and coding of transmissions. Rate adaptation is the problem of choosing the best transmission mode for the current channel and in these systems requires choosing both the level of spatial multiplexing and the modulation and coding. Hydra is an experimental wireless network node prototype in which both the MAC and PHY are highly programmable. Hydra's PHY is essentially the 802.11n PHY, and currently supports two antennas and the same modulations and codings as 802.11n. Because of limitations of our hardware platform, the actual rates are a factor of 10 smaller than 802.11n. The MAC is essentially the 802.11 MAC with extensions, including the ability to feedback channel state or rate information from the receiver. Hydra was designed to allow experimentation with real radios, PHYs, and network stacks over real-world channels and it is well suited to studying rate adaptation in multi-antenna systems. To allow controlled experimentation, we also have the ability to perform experiments over emulated channels using exactly the same MAC and PHY used for RF transmissions. We present rate control experiments based on transmission over both real and emulated channels. Our experiments include measurements for single antenna systems and two antenna systems using a single or multiple spatial streams. We study rate adaptation algorithms using both explicit and implicit feedback from the receiver. A novel aspect of our results is the first experimental study of adaptation between single and multiple spatial streams for 802.11n style systems.

As data rates supported by the physical layer increase, PHY and especially MAC overheads increasingly dominate the throughput achievable by wireless networks. A promising approach for reducing these overheads is to aggregate a number of frames together into a single transmission. The 802.11n standard uses such an approach for unicast frames. We present the design of a system that can aggregate both unicast and broadcast frames. Further, the system can classify TCP ACK segments so that they can be aggregated with TCP data flowing in the opposite direction. A novel aspect of our work is that we implement and validate our design not through simulation, but rather using our wireless node prototype, Hydra, which supports a high performance PHY based on 802.11n. Our validation shows significant improvements in throughput for each kind of aggregation we support.