[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipse.org-architecture-council] November 7th Conference call agenda
|
Unfortunately, I will not be able to attend today's meeting.
Regards,
John Graham
Staff Software Engineer
Sybase, Inc.
telephone: (978) 287-1634 (GMT - 5)
e-mail: john.graham@xxxxxxxxxx
Harm Sluiman
<sluiman@xxxxxx.c
om> To
Sent by: "eclipse.org-architecture-council"
eclipse.org-archi <eclipse.org-architecture-council@e
tecture-council-b clipse.org>
ounces@xxxxxxxxxx cc
g
Subject
Re:
11/08/2005 07:48 [eclipse.org-architecture-council]
AM November 7th Conference call
agenda
Please respond to
"eclipse.org-arch
itecture-council"
<eclipse.org-arch
itecture-council@
eclipse.org>
I missed last months call (totally miss the window for the homework ;-))
and can't make it today, but I would like to make a few comments in the
spirit of trying to get some threads going in the mailing list.
I think the path of blockitecture that shows functional areas of a project
and the inner and interdependencies on other blocks is the top level to
start with. Perhaps the blocks are like super features., and can be drilled
into to see plug-in cross dependancies. This is where we started last year,
and how we structured the TPTP pages, but we did not get consistency across
projects. This can define technical structure.
I think Wenfeng's idea bring this structure to the human level, and writing
some functional use cases that span projects is a good thing, although hard
at times. I believe each project should commit to some viewlets/flash walk
throughs of their project functional area. Most are doing this. On top of
that there are some walk throughs that can span projects without show all
the intricate details of each. I know that doing a TPTP centric demo that
crosses WTP, JDT, TPTP and BIRT positioning goes over very well with users
and developers alike. I am creating a viewlet that does this now, and would
encourage other leads to try the same intentional effort, if for no reason
but to force awareness of cross project collaboration potential.
In the past the only way I have seen successful cross big project
demo/architectures etc. is when a single person is given the job to deliver
it. I am not sure we have such a person in this case so the best efforts of
many seem to have to do ;-)
Thanks for your time.
--------------------------------------------------------------------------
Harm Sluiman, STSM,
phone:905-413-4032 fax: 4920
cell: 1-647-300-4758
mailto:sluiman@xxxxxxxxxx
Admin : Arlene Treanor atreanor@xxxxxxxxxx Tie: 969-2323 1-905-413-2323
Bjorn Freeman-Benson
<bjorn.freeman-benson@xxxxxxxxxxx
> To
Sent by: eclipse.org-architecture-co
eclipse.org-architecture-council- uncil@xxxxxxxxxxx
bounces@xxxxxxxxxxx cc
Subject
11/08/2005 01:11 AM [eclipse.org-architecture-c
ouncil] November 7th
Conference call
Please respond to agenda
"eclipse.org-architecture-counci
l"
Monthly Architecture Council Conference Call
Second Tuesday of each month, 8am PST, 11am EST
613.287.8000
or 866.362.7064
passcode 874551#
1. Changing the call time/date in Q1? A number of people cannot make
the second Tuesday of each month calls, so shall we try a different day
and/or time in Q1?
2. Outline what we want to have in the Architecture Council section
of the Roadmap. We need to collectively decide what we want to show for our
time this year - what sort of documentation of the current architecture are
we (which mostly means you all) willing to spend time writing for the end
of the year? The answer might be (disappointingly) "very little", but now
is the time to step up to the task or to state definitely that we won't be
doing much.
Last month we decided "We discussed what we should be creating for
the architecture diagram for the Roadmap. Is it a summary of the
current state? Is it a discussion of the future and forward looking
architecture? Is it useful to the existing projects or is it just
seen as a waste of time providing no benefit to the teams? We
concluded that we needed to have documentation of the existing
architecture before we could do anything more forward looking so we
resolved (ok, ok, Bjorn browbeat everyone into agreeing) to spend a
half-hour writing up their current view of the Eclipse Platform
architecture. These emails might provoke discussion on our mailing
list, plus Bjorn is going to merge these all into a discussion
document for our next call."
3. Using our decision for (2) we will review our inputs from the
last meeting and decide what we can do next to produce the Roadmap. The
inputs from the last meeting were very varied:
David Williams: documents and diagrams showing the dependencies
between WTP subsystems
Richard Gronback: list of subsystems across Eclipse
John Graham: traditional boxes view of subsystems seen by DTP
Bjorn Freeman-Benson: list of subsystems across Eclipse
Kevin Haaland: list of sub-projects and plug-ins and key components
in the Platform
Wenfeng Li: list of subsystems across Eclipse grouped by scenarios:
tools, designer, deployment
Kai Nyman: agreed with Wenfeng about using use-case scenario-based
architecture diagrams
Tim Wagner: no input
Michael Scharf: no input
4. Finally, we will talk about agenda items for the Council
meetings.
The Lattix folks have offered to come to the Council meetings and
show us what they have been extracting of the Eclipse architecture
using their tools.
???
_______________________________________________
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council
_______________________________________________
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council
