Minutes for 2013-01-15
Attending: Nick, Mike L, Mike F, David, Steve S, Niklas, Gray
Nick reminded the group that all active participants must sign the WPA. For those who are unable to do so, we will hold a monthly informational meeting, open to all interested parties, but we also strongly recommend that you contact Steve Speicher or some other member of the Steering Committee to discuss the roadblocks preventing your signing.
The wording for version skew was discussed, and agreed after Nick made one more tweak to allow different scenarios for providers with and without support for version skew within a configuration.
Initial wording was provided for change set, but Nick needs to refine this. Mike L wondered where change sets were defined, and mentioned that some systems do not support such things. Nick described how the link from a change request to a change set was defined by the OSLC Change Management spec, but that the definition of a change set resource was left to the Configuration Management spec (originally the OSLC SCM spec). We agreed that the change set might have to be a resource synthesized by a provider from the actual set of changes linked directly to a change request (via some link type not defined by OSLC), so our scenarios could not explicitly describe how change set resources are created or managed - that is, a POST or PUT on a change set might fail, and only the result of a GET would be defined. In our scenarios, links between change sets and modified or new resources would be created implicitly when a resource was modified, and would not be created by explicit client action.
At Gray’s suggestion, Nick added an entry for context to the terminology page. A context is probably either a configuration or a configuration specification or something similar.
We then discussed the PLM Systems engineering change scenario scenario. Nick tried to relate the contexts for steps a4, a5, and a6 with the contexts identified in the text after steps a1, a2, and a3, believing that the context for a4 was intended to be the third of the identified contexts (the context of the workspace …). After some discussion, it was realized that there are really four contexts, not three:
- The context against which the issue is being reported.
- A context representing the target in which the change will be delivered.
- A context (baseline?) identifying the appropriate versions of resources as a starting point for applying the change.
- A context representing the workspace in which the change is developed, and which will contain new versions of modified resources.
Nick also questioned the need to describe locking explicitly in steps a5 and a6, since some configuration management systems do not support locking in this way (for example, they might just support private workspaces, where two or more parallel such workspaces may exist, and any concurrent changes would have to be resolved or merged). After some discussion about the difficulties in wording scenarios in a general but vague way, Mike L suggested that it would be better to write different scenarios to cover the two different modes of operation. Nick and Gray have an action item to work on new or elaborated scenarios, including ones that work for providers that do not use locking.
Action items:
- Nick to refine change set definition
- Nick and Gray to refine scenarios, possibly splitting them into multiple sets for different provider capabilities
- Nick to provide strawman definition of context
