1. Community, Artifacts, and Versions André van der Hoek Institute for Software Research University of California, Irvine andre@ics.uci.edu

2. Community Set of people working together towards a common goal Here, we concern ourselves to those communities that are involved in the joint production of artifacts Intrinsic need: coordination

3. Limitations in Coordination Ability Group size Location of group members Technology Artifacts

4. Conceptual VisualizationStrengthsWeaknesses Formal, process- based coordination Scalable; Control; Insulation from other activities; Group-centric Resynchronization problems; Insulation becomes isolation Informal, awareness- based coordination Flexible; Promotes synergy; Raises awareness; User-centric Not scalable; Requires extensive human intermediation Typical Coordination Mechanisms

5. Conceptual VisualizationStrengthsWeaknesses Formal, process- based coordination Scalable; Control; Insulation from other activities; Group-centric Resynchronization problems; Insulation becomes isolation Informal, awareness- based coordination Flexible; Promotes synergy; Raises awareness; User-centric Not scalable; Requires extensive human intermediation Continuous coordination Expected to be the strengths of both formal and informal coordination To be discovered by the proposed research Continuous Coordination

6. Configuration Management “Configuration management (CM) is a discipline whose goal is to control changes to large software through the functions of: component identification, change tracking, version selection and baselining, software manufacture, and managing simultaneous updates (team work).” Walter Tichy, SCM-1, 1988

7. Construction Building Snapshots Regeneration Optimization Construction Building Snapshots Regeneration Optimization Auditing History Traceability Logging Auditing History Traceability Logging Components Versions Configurations Baselines Project contexts Components Versions Configurations Baselines Project contexts Spectrum of Functionality Susan Dart, SCM-3, 1991 Accounting Statistics Status Reports Accounting Statistics Status Reports Process Lifecycle Task mgmt. Communication Documentation Process Lifecycle Task mgmt. Communication Documentation Controlling Access control Change request Bug tracking Partitioning Controlling Access control Change request Bug tracking Partitioning Team Workspaces Merging Families Team Workspaces Merging Families Structure System model Interfaces Consistency Selection Structure System model Interfaces Consistency Selection

8. Three Generations of CM Systems Functionality Time Research Development 1 st : version control 2 nd : configuration management 3 rd : process-based CM

9. A Typical Development Scenario CM repository Pete’s workspace CBA Ellen’s workspace ECD CD D C C

10. Direct Conflicts CM repository Pete’s workspace CBA Ellen’s workspace ECD Conflicting changes to the same artifact CC C D D

11. Indirect Conflicts CM repository Pete’s workspace CBA Ellen’s workspace ECD Conflicting changes to different artifacts CC C D D

12. Traditional CM Approaches Coordination mechanism Direct conflicts Indirect conflicts PessimisticLocking before changes are made Avoided, at the expense of project delays Not addressed OptimisticAutomated merging after changes have been made Resolved, except for overlapping changes Not addressed

13. Key Observations A CM workspace in reality provides two kinds of isolation: –Good isolation  Shields developers from parallel changes to artifacts –Bad isolation  Hides knowledge of what artifacts other developers are changing Opportunities for breaking isolation are limited –Based on repository information only –Initiated by developer only –Addressing direct conflicts only

14. Objective To increase awareness of ongoing workspace activities –Collect –Distribute –Organize –Present To do so automatically and continuously –Push information To, thereby, move earlier the point at which potential direct and indirect conflicts can be detected

15. Solution New situation: Share information when others perform CM operations, and not just when I perform a CM operation Old situation: Information available only when I carry out a CM operation or explicitly request information CM repository CM repository

16. Palantír Architecture CM repository Workspace Event wrapper Event service CM clientCM serverCM client Visualization(s) Event wrapper Internal state Extractor Visualization(s) Internal state Extractor

17. Event TypeIndication PopulatedArtifact has been placed in a workspace UnpopulatedArtifact has been removed from a workspace SynchronizedArtifact has been synchronized with repository ChangesInProgressArtifact has changed in a workspace ChangesCommittedArtifact has been stored in repository ChangesRevertedArtifact has been returned to its original state AddedNew artifact has been added to workspace RemovedArtifact has been removed from workspace RenamedArtifact has been renamed MovedArtifact has been moved from one artifact to another SeverityChangedSeverity of changes to an artifact has changed Types of Events

18. Typical Sequence of Events Pessimistic Populated ChangesInProgress SeverityChanged … ChangesCommitted ChangesInProgress SeverityChanged … ChangesCommitted UnPopulated Optimistic Populated ChangesInProgress SeverityChanged … ChangesCommitted ChangesInProgress SeverityChanged … ChangesCommitted UnPopulated

19. Event Wrapper Tasks –Intercept workspace activity –Interpret workspace activity –Determine whether the activity is relevant to Palantír –If relevant, gather information regarding the activity –Construct and emit one or more events Unique per CM system –Wrap command line –Use standard facilities (triggers, virtual file system) Can and should remain unobtrusive

20. Internal State Tasks –Maintain overview of activities in both the local and remote workspaces –Subscribe to relevant workspace activities  Those pertaining to the artifacts in the local workspace but occurring in other workspaces  Siena-based event routing –Bootstrap new workspaces with information on existing workspaces Same for every CM system Always remains unobtrusive

21. Extractor Tasks –Further narrow down the events to be viewed  Set of workspaces  Set of authors  Set of artifacts  … Same for every CM system One-time obtrusive

22. Extractor

23. Visualization Tasks –Organize and display events Same for every CM system Varying degrees of obtrusiveness –Ticker tape –Tabular –Explorer –Fully graphical

24. Ticker Tape

25. Tabular

26. Explorer

27. Fully Graphical

30. Severity Currently calculated as the percentage of lines of code that have changed –Simple –Not completely accurate  1 line change to an interface  1000 lines renaming a variable Work in progress –Other severity measures –Impact measures

31. Continuous Coordination Palantír addresses the first part of continuous coordination: information exchange and awareness Palantír still needs to address the second part of continuous coordination: allowing developers to act upon the information –Part is done subconsciously –Part should be supported explicitly

32. Conclusions Palantír is a novel prototype that raises awareness of workspace activities –Maintains good isolation while overcoming bad isolation –Based on workspace information –Automated (push instead of pull) –Addressing direct and indirect conflicts Palantír is a demonstration of continuous coordination, combining formal (CM system check-in/check-out) with information (awareness) mechanisms –Can we extend the same principles to other activities (e.g., design, …)?

33. Future Work Case study to determine the effectiveness of Palantír –Does it reduce the number of conflicts? –Does it improve coordination? –Does it speed up development time? Further support for indirect conflicts –Impact analysis –Dependencies Develop additional visualizations