[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[eclipse.org-architecture-council] Architecture Council conference call Wednesday April 27th 10am PDT, 1pm EDT, 7pm CEST
- From: Bjorn Freeman-Benson <bjorn.freeman-benson@xxxxxxxxxxx>
- Date: Tue, 26 Apr 2005 19:29:50 -0700
- Delivered-to: email@example.com
- Organization: Eclipse Foundation Inc.
- User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)
Reminder: there is an Architecture Council conference call Wednesday,
April 27th 10am PDT, 1pm EDT, 7pm CEST. The call-in numbers are:
pass code 874551#
The main purpose of this call is to set the agenda for the May 17-18
Architecture Council meeting in Portland, Oregon. To quote from the
Eclipse Development Process document, the "Architecture Council is
responsible for development, articulation and maintenance of
the Eclipse Platform Architecture. This Council is responsible for ...
protecting the architecture from inadvertent corruption."
Agenda for this call:
* Reminder to make your hotel reservations for the Council meetings
* Review of the Council meetings schedule:
- Tuesday afternoon is the Architecture Council "deep dive"
meeting; I suggest that we use this time to discuss the
most important of the issues below; our final action of
the day will be to choose a deep dive topic for our next
face-to-face meeting in August.
- Wednesday morning is the plenary meeting with all three
Councils for the Requirements Council members (especially
the Strategic Consumers) to present and explain the requirements
- Wednesday afternoon is the second Architecture Council
session to discuss the architectural consequences of the
*Agenda for the May Council Meeting*
Note that this call is mostly about the agenda for the Council meetings,
not so much the actual discussion. We should add these items to the
agenda for the meeting if anyone on the call thinks it is important. We
probably should not spend too much time on the call discussing the pros
and cons - just whether we need to bring the item up in Portland.
* Add to the Council agenda: how to identify and resolve overlaps
between projects. For example (and only as an example) DTP and WTP both
have data access tools. Another examples is that both DSDP and CDT (and
probably PTP) have remote machine control issues. We need to develop a
core competency in this area - how are we going to do that?
* Add: Should the RCP become it's own PMC down the road?
* Add: what kind of filters should we have for new Eclipse projects?
Should we categorize the projects (top-quality, tool-quality,
technology-exploration, research, ...) and have different
quality/entrance/exit/etc measures for each? How are these constraints
going to be communicated and enforced?
* Add: what should it mean to have the Eclipse brand attached to a
project; what are the quality requirements?
* Add: As the technical leaders for Eclipse, the Architecture Council
members should actively participate in the various Reviews, especially
those of the top-level projects. I have posted a draft Release Review
procedure http://www.eclipse.org/org/processes/release-review.html We
should discuss, revise, and endorse a procedure for these reviews and
the other reviews. (@ see below)
* Add: Along with the Release Review procedure is a draft definition
of the quality of APIs that should be supported. Again, we should
discuss, revise, endorse, and work with our respective PMCs to enforce a
* Add: Should there be a Languages PMC?
* Add: Should we put energy behind the separation of APIs inside the
JDT so that new languages are easier to add? If so, how are we going to
make that happen?
* Add: As Eclipse is getting more and more things built on top,
developers are getting multiple Eclipse instances installed on their
machines. See http://www.theregister.co.uk/2005/03/14/eclipse_comment/.
We need to start thinking about Eclipse as a Platform and what that
could mean for distribution. Perhaps a DirectX-style where apps check
for what's on the machine could be a workable approach. Perhaps we
define the "platform" in this context to be RCP, rather than the full
* Add: A strategy for dot-NET tooling and dot-NET <-> RCP interop.
* Add: We need a policy for schema namespaces just like we have a
policy for component namespaces. For example, should BIRT have
"http://www.eclipse.org/schema/2005" or should it be
"http://www.eclipse.org/schema/birt/2005" or something else altogether?
* These are just my list of Council meeting agenda items; I'm sure
you'll have many more so we will gather them and add them to the
*A Few Action Items*
* As the technical leaders of Eclipse, we need to be more active in
filtering and quality control of the projects. I encourage you to
speak up when there are projects you are concerned or unclear about.
We need to make sure the Eclipse reputation for quality continues.
* If we have time on this call, we should take up the active discussion
of the (@) item "Release Review agenda and API quality". Our first
Release Reviews will occur before our face-to-face meeting in Portland
so it would be good to have some discussion of this topic in advance.
* The penultimate agenda item for this call is to sort the Council
meeting agenda in priority order.
* The final agenda item for this call is to assign homework for the
various agenda items. The goal is for selected Council members to
come to the Council meetings with background information on each
agenda item so that the discussions at the meeting can be focused
Technical Director, Open Source Process and Infrastructure
voice: 971-327-7323 (PDT, GMT-8)