[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [alf-dev] ALF Source CodeMangementVocabularyMeeting+1-303-928-3232 id 6053141# Wednesday10:00AM PDT - meeting minutes
|
I will not be able to attend the meeting because a previous meeting is
running long.
-Robert
-----Original Message-----
From: alf-dev-bounces@xxxxxxxxxxx [mailto:alf-dev-bounces@xxxxxxxxxxx]
On Behalf Of Tim Buss
Sent: Tuesday, August 08, 2006 8:55 PM
To: ALF Developer Mailing List
Subject: RE: [alf-dev] ALF Source
CodeMangementVocabularyMeeting+1-303-928-3232 id 6053141#
Wednesday10:00AM PDT - meeting minutes
There will be a ALF Source Code Management Vocabulary Meeting this week,
Wednesday Aug 9th at 10:00AM PDT
The call in number is
+1-303-928-3232 id 6053141#
as usual
Agenda
0. Last meetings's minutes (below)
1. Status on tasks (see list in minutes below)
2. How close are we?
3. Any other business
Tim Buss - Serena.
-----Original Message-----
From: Tim Buss
Sent: Wednesday, August 02, 2006 4:29 PM
To: 'ALF Developer Mailing List'
Subject: RE: [alf-dev] ALF Source Code
MangementVocabularyMeeting+1-303-928-3232 id 6053141# Wednesday 10:00AM
PDT - meeting minutes
Meeting minutes for the ALF Source Code Management Vocabulary Meeting on
Wednesday Aug 2nd at 10:00AM PDT
Agenda
0. Last meetings's minutes (below)
1. Status on tasks (see list in minutes below)
2. Progress on the Data model and Schema and WSDL
3. Revision Specification (see T21)
4. Any other business
Attendees
Tim Buss
Mark Phippard
Adam Simantel
Robert Reising
0. Last weeks minutes were accepted. No additional comments were noted.
1. Tasks
Completed
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
This is essentially done for now. The task now is to refine what we
have. I have created a new task (T24).
T17.
Create a schema from the data model.
Tim has create a set of type definitions from the main data model and
workspace.
Workspace still needs to be addressed. Revision Specification need more
discussion (see T21) A first draft has been added to the wiki for
review.
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 was discussed today. See meeting notes below.
T22. Create WSDL for operations
A first draft has been created and added to the wiki for review
Todo
T19
Wiki pictures. There are some placeholders for pictures in the Wiki.
These need to be populated. In particular it would be good to get the
updated data model into the Wiki
T23 Define SCM events XML
Assigned to Tim
T24 Refine and Normalize Operations so they work as a coherent set
Assigned to you. Please provide feedback
T25 Reflect Operation refinements in Schema and WSDL Assigned to Tim
T26 Discuss dynamic "Callback" idea
A point was raise that perhaps raising an ALF Event for every
asynchronous action completion may be too heavyweight. An alternative
using a dynamic callback service passed with the operation was
suggested. This would probably tale the form of an ALF event in
definition but would connect back to the calling instance of the service
flow directly. The removes the need to create new service flow instance
and simplifies data correlation in some cases.
2. Progress on the Data model and Schema and WSDL A first draft schema
and WSDL have been posted to the Wiki. Please review and provide
comments and questions.
3. Refine the idea of "Revision Specification". Define the common use
cases.
The notion of "Revision Spec" applies to any "query" specification that
locates a set of one or more Element versions. The main question is
whether it is useful for ALF to able to dynamically create such specs
and to what level of complexity.
The main operations this appears to apply to are "UpdateWorkset"
(Workspace really) and "reporting". We have decided to defer
considering reporting for now.
For the Workspace we think it more likely that a pre-defined
configuration is the most useful for ALF. That is, ALF would not
typically dynamically build a "Revision Specification" to populate a
workspace but would pass in a tool specific configuration that the
workspace service would use to populate itself. We agreed that ALF
probably doesn't need to know (or specify) the details of this and that
the tool specific configuration can in most cases be opaque (ie a
string) or hidden from ALF (ie a name that references a configuration)
That said there may be common cases that may be convenient for ALF to
dynamically specify. These are likely to be fairly simple (eg Tip of
branch, this Label, this baseline ) and ALF could define with reasonable
confidence that most implementations can support them. ALF would not
define a way to combine these into a single workspace specification
(Note: I suppose as an optimization we might suggest that these be used
to define a sequential list as a short hand way of saying "get this, get
this, get this". This seems useful for ChangeSets in particular. I'm
thinking something like a sequence getBaseline, getChangeset 1,
getChangeset 2.... Combined into a single call)
We think that the most useful AddVersion, NewElement type of operation
for ALF is to ask the Workspace to "commit" based on its current
content. In this way once the workspace is configured ALF doesn't need
to be concerned about the detail of what actually gets committed and how
that gets specified.
(Note: this idea was discussed in the Build Vocabulary meeting and seems
to be compatible with the ideas there. The notion of reports was
discussed and it does occur to me that workspace content provides a
useful "report source" for many cases and it may be useful to allow the
workspace "tree" to be walked at a logical level to provide specific
information and provide an XML "report" of its tree for the complete
content report. The workspace could provide the tree data either by
caching the meta data when it materializes the elements or by running a
"query" on the server as if it were populating)
We also agreed that much of the detail for this will come from refining
the operation definitions and that that should be the next step.
4. No other business was raised.
Tim Buss - Serena.
-----Original Message-----
From: Tim Buss
Sent: Wednesday, July 12, 2006 4:19 PM
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 the ALF Source Code Management Vocabulary Meeting on
Wednesday July 12th 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: alf-dev-bounces@xxxxxxxxxxx [mailto:alf-dev-bounces@xxxxxxxxxxx]
On Behalf Of Tim Buss
Sent: Tuesday, August 01, 2006 6:27 PM
To: ALF Developer Mailing List
Subject: RE: [alf-dev] ALF Source Code
MangementVocabularyMeeting+1-303-928-3232 id 6053141# Wednesday 10:00AM
PDT -meeting minutes
Meeting minutes for the ALF Source Code Management Vocabulary Meeting on
Wednesday July 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 (see attached)
3. Events
4. Any other business
Attendees
Richard Title
Mark Phippard
Eric Minick
Tim Buss
0. Last weeks minutes were accepted. No additional comments were noted
except I had the date wrong.
1. Tasks
Completed
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 added some "user stuff"
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
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
The schema was given a quick review.
It was noted that two spellings of Label were used.
Some of last meetings discussion may not be reflected in the
schema and that should be reviewed.
It was noted that timestamp is currently a string and since time
is important to SCM it was thought better if the schema datetime type
was used.
3. Events
We walked through the various proposed operations and discussed the
events that might result. My notes are not good on this CreateWorkspace
no event needed?
ModifyWorkspace
no event needed?
RemoveWorkspace
no event needed?
AddAssets
Seems similar to CreateNewVersions
a NewElementVersion event seems useful. An issue would be if
there 100s at once as a project gets checked it.
RemoveAssets
ElementRemoved seems reasonable. Probably not a core ALF
scenario IntentToModify
Not clear what the ALF scneario would be. An issue would be if
there are 100s of locks at once if a project gets locked. May need an
event it it could be slow.
CreateNewVersions
(see AddAssets)
CreateStream
NewStream event seems reasonable. Probably not a core ALF
scenario. May need an event if it could be slow.
CreateBaseline
NewBaseline event seems reasonable. Might be connected with a
build. May need an event if it could be slow.
UpdateWorkset
WorksetUpdated (Workspace surely?) Probably the trigger to
start the build CompareElementVersions
CompareComplete event seems reasonable. Might be connected with
a build. May need an event if it could be slow.
Merge
Merge does not seem like a good candidate for ALF since it can
fail in ways that cannot be detected. If it is useful then it may need
an event if it could be slow.
Promote
ElementVersionPromoted seem a bit to granular.
ElementVersionsPromoted seems more useful
3. Any other business
A point was raise that perhaps raising an ALF Event for every
asynchronous action completion may be too heavyweight. An alternative
using a dynamic callback service passed with the operation was
suggested. This would probably tale the form of an ALF event in
defintion but would connect back to the calling instance of the service
flow directly. The removes the need to create new service flow
instance and simplifies data correlation in some cases.
Tim Buss - Serena.
-----Original Message-----
From: Tim Buss
Sent: Wednesday, July 12, 2006 4:19 PM
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 the ALF Source Code Management Vocabulary Meeting on
Wednesday July 12th 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.
**********************************************************************
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.
_______________________________________________
alf-dev mailing list
alf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/alf-dev
_______________________________________________
alf-dev mailing list
alf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/alf-dev
