SCM Meeting 2010-03-10

Agenda:

• Review changes to spec
• Review issues list

Minutes:

Present: NickCrossley, SamitMehta, SteveSpeicher, ScottBosworth, PaulKomar

Nick asked about possible consumers of the API, and Samit confirmed that we had not as yet identified any committed non-IBM consumers of the SCM services. Smart Bear might look at it after we have completed the spec and have some implementations.

Nick then described the recent changes to the resource definitions. Configuration and component have been simplified and clarified: configuration is used everywhere that is appropriate for a collection of versioned objects (configuration items), and component is used only for settings boundaries for recursion. A component can be implemented as a configuration, or by certain property values such as a component name attribute, etc.

Nick has added the baseline compare operation, but we still need to define the results of that operation. Nick, Peter and Paul were asked to write up email to the SLC list, or a wiki page, illustrating the current results of the Rational tools for baseline compare. We probably need lists of objects added, versions removed, versions modified, and similarly for change sets.

Nick also explained some changes he had made to the resource definition for symbolic links; the new definition has more flexibility, allowing providers to have links to file system paths or to other resources, and removes the need for any explicit follow_links parameter.

Steve wondered if some of the resource definitions and operations currently described in the OSLC SCM spec were too low level, and if and how clients would use them. Paul and Nick talked about how the resources, properties, and operations in OSLC SCM were driven by the code review and code browsing scenarios - possibly with some bias towards higher-end systems that provided change sets, symbolic links, etc., while still allowing for simpler providers.

We had some discussion about access to provider-specific properties. It is standard practice in OSLC for providers to be able to return additional properties (and additional resource types) beyond those in the specs; a different question is whether or not a client should be able to query using an arbitrary set of provider-specific property names, even if some or all of those names are those of properties normally mapped to an OSLC defined property. For example, should an SCM client be able to query for change sets with the Synergy-specific property "synergy:release" as well as being able to do so using the equivalent mapped OSLC property "oslc_scm:stream"? There was some doubt about whether or not clients needed to be able to do this, but it also seems that it would quite likely work without any extra effort, since provider would need to support their provider-specific property namespace anyway, to access the additional unmapped properties. However, there appears to be no need to make the spec define this behavior.

On the question of impact analysis queries (finding all baselines or configurations using some given object or change set), the group agreed that this was useful but beyond the scope of the agreed scenarios for SCM v1.0.

We then discussed which resource representations SCM would require. The core spec will define a fairly simple transformation of representations, so the cost of supporting each new representation is fairly low (but not zero). Paul wanted OSLC to require both RDF+XML and JSON - the latter because there is increasing use of JSON in web-based clients. Nick agreed to propose just these two formats as required; providers were of course at liberty to support additional formats.

Scott asked if the intent was for SCM 1.0 to be based on the new Core spec, and Nick confirmed that was the current intent - and was one of the main reasons for the change in end date for the spec.

Paul said he planned to send a message to the SCM mailing list asking for a link from change set to task (change request) to be added to the spec. Nick asked if this went against the OSLC recommendation of representing links from one end only, to avoid potential duplication of data with concomitant risk of inconsistency. There was some discussion about this, with the conclusion that the issue needed to be brought up in a wider context.

At the end of the meeting, Scott went over the recent Eclipse announcements concerning the Mylyn projects, where new sub-projects for integration were to be created, including tasks (CM), SCM, code review, and build, and those projects were to use OSLC interfaces.