RE: [alf-dev] ALF Source Code Mangement VocabularyMeeting+1-303-928-3232

["Tim Buss" <TBuss@xxxxxxxxxx>]

Meeting minutes for the ALF Source Code Management Vocabulary Meeting on
Wednesday June 28th at 10:00AM PDT

Agenda
0. Last meetings's minutes (below)

1. Status on tasks (see list in minutes below)

2. Data model and Schema

3. Any other business

Attendees
Richard Title
Adam Simantel
Brian Carroll
Tim Buss
Eric Minick

0. Last weeks minutes were accepted.  No additional comments were noted.

1. Tasks

Completed
T11. Integration based use cases
We decided that this was being discussed extensively as part of the
build use case and that we can piggy back off that discussion.  This
will become important once we have the proposed schema/WSDL since we
will need to apply the use case filter to determine if we have a
reasonable definition (ie useful but not overreaching)

T16.
Update Data model based on ALF meeting feedback.
Brian sent out the updates.

Todo

T15.
Expand "primitive" use cases to include more detail (eg datatypes,
method signatures) Richard made some updates.  Adam committed to update
the items he signed up for and resend the email soliciting for
volunteers to address the remaining items

T17.
Create a schema from the data model. 
Tim has create a set of type defintions from the main data model.
Workspace still needs to be addressed.  Revision Specification need more
discussion (see T21)

T19
Wikki pictures.  There are some placeholders for pictures in the Wikki.
These need to be populated.  In particular it would be good to get the
updated data model into the Wikki

T20 Add the notion of User to the concepts User is an important concept
to SCM since a primary function is to attribute changes to particular
authors

Eric agreed to take this on.

T21. Refine the idea of "Revision Specification".  Define the common use
cases.
There are several ways this could be expressed. For example:
A) as an opaque string to ALF
B) as a formal set of "objects" that can be related in some formal way
C) as an ALF defined "language string
D) some combination of above.
It seems that there are some common use cases (eg get "latest" from
branch) that should be defined explicitly by ALF but there are many
other cases.  It seems unwise for ALF to attempt to define a fully
generalized approach.  For this cases ALF should just allow the
underlying tool to extend the ALF services or provide tool specific
services. We need to decide what cases make sense for ALF to formally
define.

This should be an agenda item for next week.

T22. Create WSDL for operations and events

2. Data model and Schema
We discusse the simplified data model.  A few changes were suggested

It seems natural that the SCM system would be identified by the service
endpoint and may not need to be explictly described as part of the data
model.  In other words the service endpoint should provide sufficient
context for the operations ALF cares about.  It was noted that SCM
provides a context relationship to all of the entities and that this was
probably best descibed through operation defintion rathter thand the
data model

Label seems to be in the correct place.  The relationship between
ElementVersion and Label might be better annotated with "refers to" or
not annotated than with "has" since, in the abstract at least, Labels
are not owned by the Element Version.

Lock seem to be in the right place on Element Version since typically
you lock the tip of a branch which would be an Element Version.

Not one argued strongly to keep the idea of Revision Identifier so it
remains gone.

It was suggested that it may be useful for an Element Version to provide
ancestor and successor IDs so that its position in an element tree could
be determined.  This is relatively cheap to do although the use case for
ALF is not immediately clear.  On the data model this can be described
with a relationship line.

StreamParent should be represented as a relationship line.  Probably
should be Branch ancestor and Branch successor to be complete.

ChangeSet and Baseline remain as sibling Version Collections with
different meanings.  It was agree that any relationship between this was
better expressed through SCM operations or would be held externally in
Build and Issue tracking tools.  The need for a relationship store as a
common service in ALF was mentioned.  This has been proposed elsewhere.

We did not have time to walk through the schema so that was left for
howework

Action items - 
Tim will prepare the workspace description for the next meeting.  T17
We need to come up this the set of operation and the events they cause.
T15 could provide an initial set

3. Any other business
Agenda items for the next meeting
"Revision Specification" (see T21)
Datamodel/schema  workspace 
Operations/Events in preparetion for WSDL

Tim Buss - Serena.   

-----Original Message-----
From: Tim Buss
Sent: Wednesday, June 28, 2006 11:43 AM
To: 'ALF Developer Mailing List'
Subject: RE: [alf-dev] ALF Source Code Mangement
VocabularyMeeting+1-303-928-3232 id 6053141# Wednesday 10:00AM PDT -
meeting minutes

Meeting minutes for ALF Source Code Management Vocabulary Meeting,
Wednesday June 28th at 10:00AM PDT 

Agenda
0. Last week's minutes (below)

1. Status on tasks (see list in minutes below)

2. Data model and Schema

3. Any other business

Attendees
Tim Buss
Eric Minick
Richard Title
Scott McGrath

0. Last weeks minutes were accepted.  No additional comments were noted.

1. Tasks

Completed
T7. Discuss "Workspace"

T18
SCM metadata difference report schema.  
We agreed to defer this for now as it does not seem to be a critical use
case.  We will re-visit it in the future.

Todo

T11. Integration based use cases
We decided that this was being discussed extensively as part of the
build use case and that we can piggy back off that discussion.  This
will become important once we have the proposed schema/WSDL since we
will need to apply the use case filter to determine if we have a
reasonable definition (ie useful but not overreaching)

T15.
Expand "primitive" use cases to include more detail (eg datatypes,
method signatures) Richard made some updates.  Tim will check with Adam.

T16.
Update Data model based on ALF meeting feedback.
Brian sent out the updates.  No one has had a chance to review to see of
the changes reflected our discussion.

T17.
Create a schema from the data model. Since the data model is in visio
this may need to be done by hand.
Tim started this.  Various issues became evident (see discussion in "2.
Data Model and Schema" below) Tim will attempt to refine sufficiently to
provide an object for discussion by next week.

T19
Wikki pictures.  There are some placeholders for pictures in the Wikki.
These need to be populated.  In particular it would be good to get the
updated data model into the Wikki

T20 Add the notion of User to the concepts User is an important concept
to SCM since a primary function is to attribute changes to particular
authors

T21. Refine the idea of "Revision Specification".  Define the common use
cases.
There are several ways this could be expressed. For example:
A) as an opaque string to ALF
B) as a formal set of "objects" that can be related in some formal way
C) as an ALF defined "language string
D) some combination of above.
It seems that there are some common use cases (eg get "latest" from
branch) that should be defined explicitly by ALF but there are many
other cases.  It seems unwise for ALF to attempt to define a fully
generalized approach.  For this cases ALF should just allow the
underlying tool to extend the ALF services or provide tool specific
services. We need to decide what cases make sense for ALF to formally
define.

2. Data model and Schema
In attempting to convert the Data model to a schema, some issues came up
and were discussed
A) objects vs ids.  The data model currently implies a ser of nested
instances.  In reality is seems more likely that the object instances
will be related by an ID and that unless we needed the object details we
would always refer to the object by ID.  It seems likely that all SCM
providers can provide a form of ID for the objects the expose to ALF.
It also seems likely that we can assume that these IDs can be passed a
strings and that the actual content of the ID can be opaque to ALF.  It
was suggested that all exposed objects should present a "display name"
and a "unique identifier".  For some providers the value of these fields
may be identical for any particular instance.  The assumption is that
the "display name" is printable and the that "unique identifier" can be
used to identify and retrieve an object instance.
B) Revision Specification (see discussion in T21 above)

3. Any other business - no other business was discussed

Tim Buss - Serena.   


**********************************************************************
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.