[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [alf-dev] ALF Source Code Mangement Vocabulary Meeting+1-303-928-3232 id 6053141# Wednesday 10:00AM PDT
|
There will be a ALF Source Code Management Vocabulary Meeting today,
Wednesday June 14th at 10:00AM PDT
The call in number is
+1-303-928-3232 id 6053141#
as usual
Agenda
0. Last week's minutes (below)
1. Status on tasks (see list in minutes below)
2. Workspace discussion
3. SCM Events
4. Use Cases
5. Any other business
Tim Buss - Serena.
-----Original Message-----
From: Tim Buss
Sent: Wednesday, June 14, 2006 3:36 PM
To: 'ALF Developer Mailing List'
Subject: RE: [alf-dev] ALF Source Code Mangement Vocabulary
Meeting+1-303-928-3232 id 6053141# Wednesday 10:00AM PDT - meeting
minutes
Meeting minutes for ALF Source Code Management Vocabulary Meeting,
Wednesday June 14th at 10:00AM PDT
Agenda
0. Last week's minutes (below)
1. Status on tasks (see list in minutes below)
2. SCM Events
3. Workspace discussion
4. Use Cases
5. Any other business
Attendees:
Tim Buss - Serena - ALF
Richard Title - Accurev
Damon Poole - Accurev
Mark Phippard - Soft Landing
Adam Simantel - Serena - SCM
Eric Minick - Urban Code
0. Last weeks minutes were accepted. Not additional comments were
noted.
1. Tasks
Todo
T7. Discuss "Workspace" -
The discussion continued in Email. There are two points of view.
1. That ALF should just specify an "API" with which to wrap the SCM
client allowing it to be installed in the same locality as a tool much
as an SCM client would normallybe but be controled by ALF to materialize
files "locally" to the tool.
2. That ALF should specify an API that and SCM server would implement
that would allow for a "common client" to be implemented. This would
allow for more sophisticated interactions such a pushing the file to the
tool. ( not sure I've really captured this one)
We still have to resolve this. I propose that 2 may be considered an
extension of 1 and if we decide it is necessary we can build on 1 to
create 2. They are not mutally exclusive. I would like to get
agreement on this so we can mke an initial proposal.
Tim to write a problem statement for discussion in nexct weeks meeting
T11. Integration based use cases
We think that most build use cases are a variant of the K Shaw use case.
(see Use Case Discussion below)
Eric has updated the Wikki description of this based on our discussion.
We need to decide if we need more. Please review the Wikki.
T15.
Expand "primitive" use cases to include more detail (eg datatypes,
method signatures) Adam and Jamey are taking a look at this. Adam has
been thinking about this and hopes to strat on this soon.
T16.
Update Data model based on ALF meeting feedback. Brian took notes and
will do this
T17.
Create a schema from the data model. Since the data model is in visio
this may need to be done by hand. No volunteers so Tim Buss will have a
go.
T18
SCM metadata difference report schema. We should capture some use cases
for this. To make it worthwhile to define a machine readable schema
there needs to be some compelling mainstream use cases that need to
leverage the report results in an automated way.
For some use cases we have identified that some concept of "user" is
necessary to make machine readable report useful.
It is still unclear what the use case is for a more detailed machine
readable report and wha the priority for specifying this is. It is
possible that most of what we need will come from the schema types we
might define from the data model.
T19
Wikki pictures. There are some placeholders for pictures in the Wikki.
These need to be poulated. In particulare it would be good to get the
updated data model into the Wikki
2. SCM Events
A new topic at least as a separate item.
We brainstormed likely and possible SCM event sources. Note: we are not
using the "concept" terminology here. It is assumed we will normailize
to that
Checkin - a new version of a file is checked. Possible issue is that it
is likely that 100s of files might get checked in at close to the same
time. This may swamp ALF with events that are not particularly
interesting Change - applies to files (eg Checkin). Could apply to any
of the SCM "object classes". Probably good to distinguish the different
change events rather than having the ALF service flow have to do it. It
is likley that you would associate a different service flow with each
class's change event.
Promote - (eg copying a set of file versions to another branch and
labelling them) BaselineCreate - Creation of a Baseline object. Create
might apply to any of the SCM "object Classes Configuration - adding,
removeing, (changing ?) ChangeSet - adding, removeing, (changing ?)
UpdateStarted, UpdateFinshed - bookend an action like "get"
Some addition thoughts as I write this.
It seems likely that for each of the SCM object classes we have defined,
that there would potentially be the following set of events:
- Created
- Updated
- Deleted
Some classes may not support all three, and some classes may raise other
events in addition.
3. Workspace
We had a short discussion on this. There was consensus that there were
cases where this is not an issue for ALF. ALF just needs to ask and it
will be done. This works where the client (eg Build) is configured to
know about SCM and they implicity share the location of the workspace.
However, this is not always the case. Many tools that operate on source
just know about the file system. It was decided that we need to write a
clear problem statement to discuss and make sure we cover the bases.
(See T7 above)
4. Use cases
Not discussed due to time (except as a task update above T11, T18)
5.
Not other business was raised
Tim Buss - Serena.
-----Original Message-----
From: Tim Buss
Sent: Wednesday, June 07, 2006 5:24 PM
To: 'ALF Developer Mailing List'
Subject: RE: [alf-dev] ALF Source Code Mangement Vocabulary
Meeting+1-303-928-3232 id 6053141# Wednesday 10:00AM PDT - meeting
minutes
Meeting minutes for ALF Source Code Management Vocabulary Meeting,
Wednesday June 7th at 10:00AM PDT
0. Last week's minutes (below - slightly edited for typos)
1. Status on tasks (see list in minutes below)
2. Component and Data Model discussion
3. Use Cases
4. Workspace discussion
5. Any other business
Attendees:
Brian Carrol
Tim Buss
Richard Title
Mark Phippard
Jamey Clark
Adam Simantel
Eric Minick
0. Last weeks minutes were accepted. Not additional comments were noted
1. Status on tasks
Done:
T12. Review and Discuss Data Model (see item below) T13. Review and
Discuss "Component" - Due to the complications it raises we decided to
drop the notion of Component for now (see item below)
Todo
T7. Discuss "Workspace" -
The discussion continued in Email. There are two points of view.
1. That ALF should just specify an "API" with which to wrap the SCM
client allowing it to be installed in the same locality as a tool much
as an SCM client would normallybe but be controled by ALF to materialize
files "locally" to the tool.
2. That ALF should specify an API that and SCM server would implement
that would allow for a "common client" to be implemented. This would
allow for more sophisticated interactions such a pushing the file to the
tool. ( not sure I've really captured this one)
We still have to resolve this. I propose that 2 may be considered an
extension of 1 and if we decide it is necessary we can build on 1 to
create 2. They are not mutally exclusive. I would like to get
agreement on this so we can mke an initial proposal.
T11. Integration based use cases
We think that most build use cases are a variant of the K Shaw use case.
(see Use Case Discussion below)
T15.
Expand "primitive" use cases to include more detail (eg datatypes,
method signatures) Adam and Jamey are taking a look at this
T16.
Update Data model based on ALF meeting feedback. Brian took notes and
will do this
T17.
Create a schema from the data model. Sicne the data model is in visio
this may need to be done by hand. Looking for volunteers otherwise Tim
Buss may take this on.
T18
SCM metadata difference report schema. We should capture some use cases
for this. To make it worthwhile to define a machine readable schema
there needs to be some compelling mainstream use cases that need to
leverage the report results in an automated way. - All
2. Component and Data Model discussion
Brian presented v3 of the data model (attached). There was general
consensus that it made sense. Some modifications were suggested.
It was suggested that maybe the notion of an ALF define meta-data
difference report should be captured. There was some concern that this
may be beyond the scope of ALF but it was generally agree that this may
depend on what use cases we consider core and what are edge and that
this was worth some further analysis. It seem likely that such a report
would be based on the same types defined by the data model and thus this
may not the that onorous to define if we think that is workwhile. It
was noted that the is already a semi-standard differnce format for file
content.
Three action items were noted (T16, T17, T18)
On the idea of "component" (see attached) it was generally agreed that
this was an abstract notion that was not universally supported by SCMs.
It was suggested that it might be useful as a concept across stores.
For now we decided to drop it and perhaps re-visit it later once the
core is defined.
3. Use Cases - not discussed due to time
4. Workspaces - not discussed due to time (see T7 above) There has been
some discussion in the mailing list on this
5. Other business - none raised
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.
