Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [] Eclipse Council MeetingsAnnoucement

There's a conflict Day 1 afternoon for those on both the Requirements
and Architecture councils...

I'll attend the calls for RC and AC.


-----Original Message-----
[] On Behalf
Of Bjorn Freeman-Benson
Sent: Tuesday, March 29, 2005 9:32 AM
Subject: [] Eclipse Council


This email is a little lengthy, but I couldn't figure out how to make it
shorter and still contain all the information.  This email covers the
Eclipse Councils so if you're receiving this, then you're on at least
of the three.


The Eclipse councils will meet in 2005Q2, 2005Q3, and 2005Q4:
  Q2: May 17, 18, 19 in Portland, OR
  Q3: August 16, 17, 18 (not yet known)
  Q4: December 6, 7, 8 in San Fransisco, CA

We're trying a little different time layout this year:
  Day 1: Requirements Council meets all day
  Day 1: Architecture Council meets in the afternoon
         for a first session
  Day 2: Plenary with all councils in the morning
  Day 2: Architecture Council meets in the afternoon
         for a second session
  Day 3: Planning Council meets all day

See below for more detail on each of these sessions.
See way below for details on the Portland meeting.


We will be meeting at the Hotel Lucia in downtown Portland.
Our meeting room rate is $129.  You'll have to make your own
reservations.  Wireless is available in the hotel for $13.95/day.
The hotel is right downtown so there are a wide variety of
restaurants, pubs, coffee houses, etc in the vicinity.
There is NO airport shuttle - the cab fare is estimated to
be around $15.


We will schedule regular monthly phone calls for each
of the councils so that we can address shorter-term issues.
The first of these calls will be:

Requirements Council
  April 26, 7pm CET, 1pm EDT, 10am PDT
     +1 613 287 8000
     866 362-7664

Architecture Council
  April 27, 7pm CET, 1pm EDT, 10am PDT
     +1 613 287 8000

Planning Council
  April 28, 7pm CET, 1pm EDT, 10am PDT
     +1 613 287 8000

Please RSVP for these calls because if too few people are
able to attend, we will reschedule the calls. But we won't
know that unless you RSVP.

See below for agendas of the calls.


The Requirements Council (RC) is being chaired by Mike Milinkovich.
The agenda for the RC conference calls and May 17th meeting will be
distributed in the near future.

The Requirements Council meets on May 17th. The RC then takes
the results of that meeting and presents them to a plenary of all
the councils on the morning of May 18th. This plenary is a new twist
on the councils whose purpose is to make sure that the valuable
conclusions of the RC are not lost in the Themes and Priorities
summaries of the first day's meeting.


The Architecture Council (AC) is being chaired by Bjorn Freeman-Benson.

The purpose of the April 27th call is to set an agenda for the May 17th
and May 18th face-to-face sessions. Specifically, I would like to choose
a technical area for the "deep dive" on the 17th. I also plan to use the
the phone call to encourage all AC representatives to provide written
status reports in advance of the May 17th meeting so that we can spend
our face-to-face time on proactive items.

The first session (May 17 PM) is a "deep dive" into a specific technical
area - an area that crosses project boundaries.  For example, we might
discuss flexible project structures.  Or something else.  The goal is
to make productive use of the high-powered design talent gathered in
the room and the high-bandwidth face-to-face communication.

The AC attends the all-council plenary (May 18 AM) in order to have the
opportunity to quiz the RC members (especially the Strategic Consumers
who have little representation on the other councils) about "what they
mean" by the Themes and Priorities and about "what are" the fine-grained
requirements that back the Themes and Priorities.

The second session (May 18 PM) is to discuss the architectural issues
surrounding the RC requirements. What will the projects need to be
working on in order to move towards the requirements in a timely
manner.  Additionally, the second session will be used to start
framing the AC input to the next Roadmap document.

A few specific issues that the AC needs to address are:
(1) What should the "Eclipse standard" for the project numbering
  be for new projects?  E.g., should it be BIRT 1.0 or BIRT 3.1?
  There are pros and cons to both choices, so we should discuss
  and then choose a standard.  Note that there is already a
  de-facto standard for major and minor numbering for existing
(2) What does it mean to be an "Eclipse Quality API"?  The Platform
  project has an effective API policy that has helped Eclipse be known
  for really high quality extensible frameworks. We should
  discuss and decide on a simple scheme for the Councils and the EMO
  to decide on when an API is ready to be released.  There are
  a number of options for such a scheme - we will debate the pros
  and cons and pick one.
(3) The COBOL and Languages PMC issues from the last AC meeting have
  not been addressed. We will need to make sure that the new
  victims of these tasks agree to spend time on them.  (I'm guessing
  the COBOL task is going to be assigned to me.)  As for the Languages
  PMC, we should decide if, and then how, to start such a thing and
  what it would look like given that time has passed and the world
  continues to change.
(4) Consider whether RCP should move to its own PMC in the future.
  What are the pros and cons of such a move, and what would it take,
  resource-wise, to make this happen?
(5) Start a listing of where our projects overlap (e.g., DTP and WTP)
  as a precursor for figuring out how to eliminate them in the future.
(6) Ok, clearly there are a lot of issues to consider and we probably
  won't get to them all. Hence the April 27th conference call to set
  the agenda.
(7) As Eclipse is getting more and more things built on top,
  developers are getting multiple Eclipse instances installed on
  their machines. See
  We need to start thinking about Eclipse as a Platform and what
  that could mean for distribution. Perhaps some scheme where apps
  check for what's on the machine could work.  Perhaps we define
  the "platform" in this context to be RCP, rather than the full JDT+PDE

  In any case, this is a topic to start working on before "plug-in hell"
  replaces "DLL hell".


The Planning Council (PC) is being chaired by Bjorn Freeman-Benson.

The purpose of the April 28th call is to set an agenda for the May 19th
face-to-face session.

The PC attends the all-council plenary (May 18 AM) in order to have the
opportunity to quiz the RC members (especially the Strategic Consumers
who have little representation on the other councils) about "what they
mean" by the Themes and Priorities and about "what are" the fine-grained
requirements that back the Themes and Priorities.

The PC meets by itself on May 19th to discuss the project planning and
resourcing necessary to align the projects with the new Themes and
Priorities.  The PC will also review the "keeping current with
relevant standards" progress of each project. We will also try to make
a push for more cross-project cooperation, or at the very least,
communication and mind-melding.  Each of the projects brings a
distinct and interesting approach to Eclipse and we'd like to find
a way to gather the best of all of them into our development processes
and conventions.

Additionally, we will use this meeting to being framing the PC input to
the next Roadmap document.  Specifically, I'd like to make sure that we
have a status format that we are, collectively, content with so that
we can all generate our Roadmap inputs at the end of the year without
a lot of extra work by any of us.

A third major item to be addressed is the upcoming Release Reviews.  The
Development Process states that "The Release Review is conducted before
each major release to verify that the key goals of the release have been
accomplished and to verify that all intellectual property rights issues
have been resolved. The review is conducted sufficiently before the
target release date to allow time to respond to feedback."  Given that
many of the major projects all plan to release in the June-July time
(around the 3.1 Platform release), and that a Release Review is a
significant time commitment by both the PMC and the EMO, we need to
schedule these sufficiently far in advance that nobody goes away

Specific issues that the PC needs to address are:
(1) We should agree on a standard format for consolidating project
  planning information. For example, it would be nice for the
  website to show a merged release cycle across all the projects
  (something like the slick TPTP slide, but for all the projects
  And it would be nice to have a simple tool that auto-gens this
  calendar rather than having Susan Iwai hand edit something.  But to
  auto-gen something, we need to decide on a common XML(?) format for
  the data and a common CVS location that it is stored in each
  repository, etc.
(2) How much "simultaneous release" or "near simultaneous" releasing
  of projects do we want to encourage or discourage?  There are pros
  and cons for both positions, so we should discuss and then take
  a position. The PC representatives will take that decision back to
  their PMCs for implementation.
(3) A related question is "what is the Platform maintenance release
  schedule" so that other projects can synchronize with it?
(4) The agenda for a Release Review.  I will distribute a proposal
  in advance of the PC meeting, although I welcome any input you
  might have.
(5) Figure out how to put more energy behind the separation of APIs
  inside JDT so that the resulting ALDT is easier to use for adding
  new languages. Of course, this is easier said than done, but
  challenges like this are why we are the PC rather than just a
  bunch of talking heads.

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

_______________________________________________ mailing list

Back to the top