Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[eclipse.org-architecture-council] Architecture Council conference call Wednesday April 27th 10am PDT, 1pm EDT, 7pm CEST
Reminder: there is an Architecture Council conference call Wednesday, April 27th 10am PDT, 1pm EDT, 7pm CEST. The call-in numbers are: 
  613.287.8000
or   866.362.7064
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:

*Logistics*

  * Reminder to make your hotel reservations for the Council meetings
    in Portland.
  * 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
        requirements.

*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 quality standard. 
  * 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 JDT+PDE stack. 
  * 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
    Council agenda.

*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
    and productive.

--
*Bjorn Freeman-Benson*
Technical Director, Open Source Process and Infrastructure
Eclipse Foundation
voice:      971-327-7323 (PDT, GMT-8)
email:      bjorn.freeman-benson@xxxxxxxxxxx

Back to the top