[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [alf-dev] Build Vocabulary Meeting Minutes
|
Title: Build Vocabulary Meeting Minutes
Here is the vocabulary
process taken from the SCM vocabulary minutes. I think the Build
discusssion has so far skirted the idea of concepts.
A. Concepts - To enumerate and describe generally the basic concepts we
are trying to capture
B. Use cases - The set of
core use cases we think are common and generally useful
C. Schema - A formal definition of the data
D. WSDL - A formal definition of the services
E. Overview - Something to tie it all
together
A general question was raised as to the scope of a
vocabulary and what we might do with functions that are not universally
supported (ie one tool supports and another doesn't) - ALF vocabularies should
encapsulate a core set of functions. Its purpose was to useful and make things
easier but not to provide rigid standard. Thus tools were welcome to provide
additional services outside of Core and there was no obligation for a tool to
provide all the functions defined by ALF. That said, the idea is that we achieve
some level of interchangeability especially in the case of Open
Source.
Unfortunately I won't be
able to attend the call this morning
Tim
Below are the combined minutes for the 6/12 and 6/19 meetings.
Attendees:
Steve Taylor
Jim Graham
Tim Buss
Doug Fierro
Brian Carroll
Eric Minick
1. Scope of a Build
We agreed that a Build is the compile and link process, even
if there is some minor
processing done such a file copies. Actions like the
check-out from SCM or Testing
are outside of the Build itself. Those Actions are part
of the Build Service Flow but not part
of the Build.
2. Reviewed the initial Build Use Cases. See
http://wiki.eclipse.org/index.php/ALF/Build_Use_Cases for details.
3. Need to add the following use cases to the Wiki:
- Approved for Build
- Human Interaction (ie. log review before service flow continues)
- Dependency Management
- Impact Analysis
- Bill of Material Reporting
- Continuos Build
4. Identified the need for persisting state related information
in the service flow.
5. Identified the need for Logging/Reporting mechanism to deal with
consolidating the
Build Logs and Reports for the End User. The information itself may
not need to be persisted but
links to it should be.
6. End User construction of Service Flows:
a. Small number of Service Flows that can be reused by passing parameters to them.
i. Outstanding issue
- What interface would be used to fill in the parameters.
b. Specific Service Flow for each Project,
location and type of build
i. Many service flows
ii. Hard to change
items in common.
Conclusion:
Parameterized Service Flow would be best for
the End Users but the End Users can create
specific Service Flows if they choose to do
so.
Next Call:
6/26 - 1PM CDT
Teleconference:
913-227-1219
Code: 176934
Agenda:
Drill down into
the Build a Change Request Use Case
--
Catalyst Systems Corporation
Ph: 800-359-8049
x114
505-424-6439
Fax:
505-424-6438
**********************************************************************
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.
