SCM Meeting 2009-10-21

Agenda:

• Review vocabulary/terminology
• Continue refining scenarios

Minutes

Present: GeoffreyClemm, JimConallen, NickCrossley, RobinFuller, PaulKomar, JeanMichelLemieux, SamitMehta, ScottBosworth, SteveSpeicher

Nick mentioned that a page had been added on comparative terminology, and the page had been filled in by various contributors.

The group then went straight into discussing the build story, starting with the issues concerning file system projections (views, work areas, etc.) and the capabilities of SCM clients and servers in handling those projections. It was agreed that in most cases, SCM clients are responsible for all management of these file system projections. Since many SCM servers have no knowledge of their clients and cannot initiate communication with them, it would not be easy for a server-based REST service to perform any action that required view or work area changes. For at least the first round of SCM services, the group therefore agreed to consider all such actions as out of scope. Build systems and other integrations can of course communicate with client using alternative APIs - and such APIs might well be more suitable than REST services for such interactions anyway.

Hence checking configurations in or out, marking and checking in build artifacts, creating or updating bills of materials, and creating baselines are all out of scope, since at least on many SCM systems they involve client activities, or are services provided by the build system and not by SCM.

Since adding tags or labels is often done as part of checking in the build configuration, and since the mechanisms for adding tags or labels vary greatly between systems, the group also decided this action is also out of scope for now.

After removing all these parts of the story, we end up with not so much a build integration story but rather a build/baseline reporting story. Combining what were the two separate stories of build integration and the work item integration, and leaving out both what is now considered out of scope and (temporarily) the integration with other parts of OSLC leaves a drill-down reporting scenario; this is still useful and valuable, and can be defined by the previously-agreed date (the end of February 2010).

Nick will write up a replacement scenario with read-only services supporting queries for baselines, and navigation from baselines to change sets, configurations to contents, change sets to associated files and directories, plus difference reporting; Nick will also start listing some of the reportable properties of these objects.

The group discussed what was meant by differences. For baselines, SCM systems can detect a number of differences, including but not necessarily limited to change sets fully added, fully removed, partially added, partially removed, partially added and partially removed, and modified. We agreed that we would define a service that returned lists of change sets fully added, fully removed, and 'other'. For files, we agreed to provide a service to get the complete contents, and a service to get a line-based file difference; support for token-based diffs and/or annotate/blame style reports could be added later. Since the services to be provided are just server-based read-only ones, no merge service would be provided.

We agreed that build context, tool sets to be used, platform choices, etc., can be retrieved as properties of the appropriate configurations and baselines, but we would not provide a service to set or modify such properties.

The group agreed that this drill-down report would be of some value, but that value would be considerably higher if OSLC defined ways to query for relationships/links across different services such as SCM, CM, RM, and QM, so that an integration could show other information for a new build or baseline, such as requirements satisfied, change requests resolved, tests passed, etc.