Architecture Council
Members,
Here is a revised agenda for our meeting that starts tomorrow.
The schedule for the meetings returns to
the "Portland style":
|
Tuesday 13 |
Wednesday 14 |
Thursday 15 |
am |
Requirements |
|
Plenary w/
Board |
Planning |
pm |
Architecture
1/2 |
Architecture
2/2 |
eve |
Group
dinner w/ Board |
|
|
Hotel
You've all already made hotel reservations, but just in case you forgot
where it is, the hotel is the
Serrano Hotel,
405 Taylor Street,
San Francisco http://www.serranohotel.com/
Agenda
Tuesday afternoon:
- [All] Choose a time for monthly Architecture Council calls. Our
calls to date have been sporadic and, to be honest, not that useful.
However, there is a theory that if we get in the habit of regular
monthly conference calls, our interactions and collaborations will
increase. Let's try it for six months and then either it will be
successful or we'll give up.
- [Harm] Discuss tools and suggestions for UI-based Eclipse
testing. Tim says that BEA uses Abbott plus some homegrown extensions.
Rich says Borland uses some homegrown tools. Harm says that TPTP uses a
UI macro record-playback tool from the PDE folks and that he'd be happy
to demo it for the AC.
- [Kevin] Status report from Kevin on the effort to use new Eclipse
wiki
(http://wiki.eclipse.org/)
to create user interface guidelines as an
improved version of the existing old Platform team UI guidelines - how
many projects have expressed interest/have joined the effort?
- [Kevin] Status report from Kevin on Activities and Activity
Categories for progressive disclosure. Kevin was going to send the
documentation to our mailing list (but I can't really complain about it
not happening because I still haven't posted the minutes from three
months ago).
- [Kevin,All] Status report on the agreed-upon change to using
ICU4J.
Wednesday afternoon:
- [All] Draft the architecture contribution to the Roadmap v2.0.
The purpose of this Roadmap is for new developers and new ecosystem
companies to get their first understanding of Eclipse plug-in
development and building extensions to the Eclipse projects.
We will put together this Roadmap as follows:
- (1 hour) As a group, we will sketch an architectural block
diagram.
- (1 hour) We will break into smaller working groups and write a
paragraph or two of prose about each block in the diagram. We will
re-group and combine these paragraphs.
- (2 hours) We will break into smaller working groups again
(different groups) and develop a list of three patterns used in each
project. The constraints are:
- The three or four most important patterns for understanding the
architecture of your project
- At least one of the patterns must be unique, i.e., we cannot
all say "the Adapter pattern" just because it is used in the core
Platform.
- Each pattern should reference its published description - on
the eclipse.org website or c2.com or the Gang of Four book or wherever
the pattern is described.
- Each pattern should cite one or two outstanding examples in the
project's code.
Ward will help us with this, obviously :-)
Group Dinner Tuesday Night
1830
cocktails, 1900 dinner at the Ponzu Restaurant (at the hotel). Those of
you who pre-registered for dinner know who you are. Those of you who
didn't - well, there aren't any seats left in the dining area, sorry.
Plenary Session Wednesday Morning
0800
- 0830: Continental Breakfast
0830
- 1000: Steven O'Grady (Redmonk): Building Communities
1000
- 1015: Break
1015
- 1100: Topic Leader: Mike Norman
I'm
very interested in interoperability amongst projects, not just in terms
of interop through the platform, but interop with each other. There
are related issues of re-use, packaging, release trains, quality etc.
There's a balance to be struck between a top-down and a bottom-up
model. This is something that I think would be a useful area for the
board to flesh out a policy. However, it's not really for EMO
execution, more something that is in scope of the Councils, so it ends
up back with the member organizations, with EMO facilitation.
1100
- 1200: Topic Leader: Bjorn Freeman-Benson
Currently,
the Board and the Projects see the development process differently. The
Board wants protection; the Projects want freedom; each side needs to
understand that there is value in the other's view and that some middle
ground is going to be the best solution.
Regards,