[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[eclipse.org-architecture-council] Eclipse Council Meetings Annoucement

----------------------------------------
WELCOME TO THE ECLIPSE COUNCILS

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 three
Eclipse Councils so if you're receiving this, then you're on at least one
of the three.

----------------------------------------
QUARTERLY MEETINGS

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.

----------------------------------------
PORTLAND, OREGON

We will be meeting at the Hotel Lucia in downtown Portland.
http://www.hotellucia.com/
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.

----------------------------------------
MONTHLY PHONE CALLS

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
    496784#

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

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

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.

----------------------------------------
REQUIREMENTS COUNCIL

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.

----------------------------------------
ARCHITECTURE COUNCIL

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
projects:
http://www.eclipse.org/eclipse/development/why_eclipse_3_0.html
http://help.eclipse.org/help30/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/api/org/eclipse/core/runtime/PluginVersionIdentifier.html
(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.
http://www.eclipse.org/articles/Article-API%20use/eclipse-api-usage-rules.html
http://www.eclipsecon.org/2005/presentations/EclipseCon2005_12.2APIFirst.pdf
http://www.eclipse.org/webtools/development/arch_and_design/pq-apis-20041115.ppt
(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 that
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 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 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 stack.
In any case, this is a topic to start working on before "plug-in hell"
replaces "DLL hell".


----------------------------------------
PLANNING COUNCIL

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 frame
(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
disappointed.

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 eclipse.org
website to show a merged release cycle across all the projects
(something like the slick TPTP slide, but for all the projects
http://www.eclipse.org/org/councils/PC/tptp/TPTP%20Project%20Roadmap%20-%2018-Feb-05.gif).
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