Contents
Agendas and Minutes
Agenda for 2012-10-30
- Review the resource definitions page
- Continue review the scenarios in the light of the updated terminology and resource definitions
Minutes for 2012-10-16
Attending: David, Mike, Nick, Peter,
We discussed the changes to the terminology page. Mike questioned the last sentence of the concept resource definition: “Links are almost always established by using the URL of a concept resource – these are the URLs you almost always see in other resources”, saying that there are quite a few cases where one does want a version-specific link, and wondered if should should introduce terms for the types of link - perhaps precise and imprecise links? David mentioned there might be three types - fixed version, most recent version in some branch, and the concept resource which would give you the appropriate version for the context configuration. Nick mentioned that the definition was originally written in this way in order to encourage the use of the concept resource URI as the default kind of link - we do not want people using version-specific links too frequently, as that would bypass configuration management. Nick agreed to re-word the text to give better guidance.
On version skew: this topic needs some discussion in the ALM-PLM WG, and we need to revisit the proposed PLM product resource representation and compare it to that used by the RELM product.
We agreed the terminology page should mention “change set” - though we are not yet sure how to define that in a way that can generalize to many possible providers. Mike believes the terminology page should also define “merge”. Other terms that we might want to define, or explicitly decline to define: merge, variant, option, dimension, view, effectivity.
We started to discuss the revised Resource Definitions, but ran out of time, and it was too important to do quickly or casually. Nick wanted to be present at the continued discussion, but will be traveling next week, so the group agreed to cancel next week’s meeting, and to resume discussion on Oct 30th.
Actions:
- Nick to re-word concept resource URI link guidance
- Nick to create an issues page, and move issues from embedded notes in other pages to this new page
- Nick to send out a description of the RDF model used by Rational’s new RELM product, since that serves as an example of how to handle version skew
- Mike to check with the ALM-PLM WG, and look at other PDM tools, before agreeing that “revision” can be treated as a synonym for “version”
Minutes for 2012-10-02
Attending: Nick, John, Peter, David, Gray, Mike
- Nick thanked David for running the last two meetings. We then discussed the minutes of previous two meetings, so that Nick could catch up.
- Nick asked about baselines just being a set of resources with some tag, and suggested we should require such providers to construct a baseline resource to represent the results of a query over such resources - the idea being to keep configurations and baselines both pretty much the same resource type, to keep things simple. The group did not object to this approach.
- Nick mentioned that there were ways of implementing ‘Compare’ that did not require enumeration of baseline or configuration contents - we could just ask each provider to return an HTML page showing a difference, and not define a way to parse that returned value. However, such an approach would not satisfy all our use cases. Mike mentioned that a separate ‘release object’ could carry the structure information. We agreed to come back to the topic of enumerating the contents of a baseline or configuration on another day, as it was a complex subject.
- David mentioned that a link to the W3C provenance group has been added to the main page.
- We discussed check out , and agreed to make it optional - but we need to review the scenarios to ensure each one can be addressed whether or not checkout is provided.
- We then went on to discuss terminology. Gray mentioned we should be careful about defining resources vs. terms - e.g. version vs. version resource, where there is a difference.
- We agreed to remove baseline as a separate type - but keep it as a term to be defined. Baselines would be represented as configurations, and we would provide a state predicate (like in OSLC Change Management) to define immutability.
Actions:
- Nick to update the terminology page, and also the resource definitions to match.
- Nick to send out note to OSLC SCM and OSLC community about this group, inviting contributors.
Minutes for 2012-09-25
Attending: David, Mike, Gray
- We discussed the PLM Systems Engineering Scenario and the CM capabilities that this requires or implies. The Configuration Management Scenarios has been updated to include details of the points discussed.
- We discussed whether CM actions such as check out should be covered in phase 1, or whether users performed these actions in the underlying tool, perhaps with a delegated UI picker to create links between configuration items or configurations and other resources such as change requests.
- We discussed the need for versioning providers to support two types of resource URIs: absolute and composite (perhaps there is a better term?). An absolute URI always resolves to the same version of a resource. A composite is composed of a concept URI plus some context that the underlying versioning provider resolves to a particular version of that resource. This resolution may change over time. Examples of context might include effectivity for PLM tools, streams for SCM tools and so on.
- We discussed whether the term configuration item should be used. See Configuration Management Terminology for details.
Minutes for 2012-09-18
Attending: David, Mike, Steve S, Niklas
- Reminded everyone to sign the new agreement forms.
- We discussed the Incremental Development Using Baselines scenario. We discussed that some systems might not have baseline as a separate resource, rather it could be a collection of artifacts tagged with some unique baseline identifier. Mike stated that baselines were treated as configurations on a stub branch. We briefly talked about what other types of artifacts are linked. Mike stated that requirements were often held within PLM tools and could be viewed and compared as they can with product hierarchies.
- We discussed Compare Baselines scenario. We discussed that one of the more important aspects of this can be determining the set of changes included in a baseline compared with some previous baseline. Also different processes might be used for this, sometimes aggregating change details from low-level artifacts to a higher level artifacts in order to make querying and reporting easier and more efficient making the predecessor property important. Mike mentioned that they also report on change requests, but they don’t call this a baseline compare.
Particular releases might have a BOM (Bill of Materials), and they can perform a comparison of BOMs. This scenario needs further development since the types of reporting and traceability is not yet described.
- We discussed how incremental development tracked changes that applied to multiple versions of a product or system. Mike stated that change requests tended to apply to a particular product version and documented the effectivity of the change - such as a date or serial number in which the change should be delivered.
- We briefly discussed predecessor/successor relations. Steve stated that the W3C WG on provenance had made some good progress. It would be useful to add a link to that W3C WG from the CM Wiki. This relates to the PLM WG proposals for core using a vocabulary of dcterms:isVersionOf and dcterms:replaces.
- We agreed that it would be useful to review scenarios from the PLM WG to see which aspects might be useful in developing CM WG scenarios.
- We discussed whether issues, comments, and questions should be edited on the scenarios page(s), or on separate pages. Steve mentioned that both practices are commonly used, but early discussion tends to be on the same page as the topic. We agreed to keep the scenarios as a single page for the moment, but it will probably benefit from splitting into several pages as the content expands.
Minutes for 2012-09-11
Attending: Nick, David, Mike, Steve S, Sandeep, Sampath, Peter, Niklas
- We discussed the current state of the OSLC Configuration Management workgroup: the rechartering has been approved by the Steering Committee.
- Nick said that the wiki has been migrated to the new wiki, and asked all members to sign revised the OSLC and workgroup participation agreements.
- Nick mentioned a suggestion that members post short workgroup member descriptions/bios on wiki; another member commented that the new wiki already allowed for that - each member has a wiki page of their own created automatically when they sign the participation agreement forms, and that page has a place for a bio. We agreed that members should post a short bio of themselves - Nick has done so, and has also added a photo.
- Nick went through the slightly revised Configuration Management Terminology page, where the group agreed that we needed to define (or specifically decline to define) version, version skew, revision, and branch - but we did not take the time to define those terms in the meeting.
- We also went through the new Configuration Management Resource Definitions page, but did not have time for any development of that page.
Minutes for 2012-08-21
Attending: Nick, David, Mike, Steve S, Sandeep, Gray, CJ Paul, Niklas, Cheryl, Kartik, Peter
- We first discussed the idea of having alternate meetings at a different time. From the Doodle poll, the best alternative was at 11am US/Pacific on Wednesday, but this was very late for everyone in Europe. After a very brief discussion, the group agreed to leave the current time (Tuesday 6am) for all meetings.
- CJ Paul and Cheryl from Tivoli introduced themselves as new members of the group.
- Nick reminded group members to add their names to the Configuration Management home page on the wiki, and to the OSLC SCM mailing list. Nick and Steve will review whether this group will continue to use that SCM mailing list, or create a new one.
- We then continued the review of configuration management and baseline scenarios, starting with ‘control the use’ - Nick and Mike elaborated the proposal for separate status/workflow objects, trying to keep baselines truly immutable. Steve made the point that with RDF, a provider cannot guarantee true immutability of a resource, since any provider can make new assertions about any resource simply by including a triple with that resource as its subject.
- Nick agreed to write a draft suggestion for the separate workflow idea, send this to Mike for review, then forward to Config Mgt, PLM, and Change Mgt workgroups for discussion.
- Nick walked through the ‘high ceremony requirement-driven development’ scenario. Mike commented how again much of this was process / workflow, and effectivity. Nick agreed, but pointed out how there were some important configuration management aspects: the ability to create configurations from scratch, the ability to create configurations that included, referenced, or depended on other configurations, the ability to freeze/snapshot a configuration, and the ability to have links in the context of a configuration.
- Sandeep suggested we need to define the terminology - and to do so in terms of specific RDF vocabulary definitions, so it would not just be ambiguous English. Nick thought that scenario elaboration and terminology / RDF vocal development had to occur somewhat in conjunction with each other, but agreed that now we had reviewed all the original use cases, it was time for a pass on terminology and vocabulary. Nick undertook to start a draft vocabulary definition on the wiki, and the group would review this draft and the terminology page next week.
Minutes for 2012-08-14
Attending: Nick Crossley, Niklas Larsen, Sandeep Kohli, Mike Loeffler, Peter Hack
- Nick asked all participants to add their names to the Config Mgt wiki.
- The group than reviewed the scenarios, starting with the primary scenario of a cross-tool, cross-domain baseline.
Mike: baseline creation is like release process - it has a workflow, many people participate, and the release is built up and then snapshotted at some time.
- Sandeep asked if we need closure of links - how do we decide what is part of a config. Nick: a baseline certainly needs to have enuerable contents, potentially found through delegation to the underlying providers. A modifiable configuration might need enumeration of contents, though is not yet completely clear. Mike - a baseline should be just a frozen config.
- Mike - not sure about having any modifiable props on baseline - prefer to handle this by having other modifiable resources for workflow process that point to baselines. Mike volunteered to demo this in PLM context, probably a bit later when more of the group was back from vacation.
- Mike also brought up the topic of variability and effectivity; we need to see how those concepts fit in with configurations, baselines, and their properties.
- Nick asked participants to review old Core workgroup baseline proposals, to see two different past approaches - even though neither of them may be quite what we want today.
Meeting Logistics
Nick Crossley will normally host the telecons. Here are the details.
Participant passcode: 73872710#
For the meeting on 11th September, 18th September, and 25th September, David Honey will host the telecons.
Participant passcode for 11th, 18th, and 25th September: 40766597#
Commonly used phone numbers
|
Toll-free Phone Numbers |
| US and Canada |
1-888-426-6840 |
| Britain |
0800-368-0638 |
| France |
0800-94-0558 |
| Germany |
0800-000-1018 |
| Israel |
1-809-417-783 |
| Sweden |
0200-12-5807 |
Additional phone numbers
Additional international dial-in numbers.
Web conference
A web conference is set up only if required - the meeting agenda will indicate this.
