Re: [eclipse.org-architecture-council] Eclipse Council Meetings Annoucem

[Harm Sluiman <sluiman@xxxxxxxxxx>]

I will attend as well.

Thanks for your time.
--------------------------------------------------------------------------
Harm Sluiman, STSM,  
phone:905-413-4032   fax: 4920  
cell: 416-432-9754
mailto:sluiman@xxxxxxxxxx
Admin : Gabrielle Chapman chapmaga@xxxxxxxxxx  Tie: 969-2323

David M Williams <david_williams@xxxxxxxxxx>
Sent by: eclipse.org-architecture-council-bounces@xxxxxxxxxxx

03/31/2005 12:47 AM

Please respond to
"eclipse.org-architecture-council"

To	"eclipse.org-architecture-council" <eclipse.org-architecture-council@xxxxxxxxxxx>
cc
Subject	Re: [eclipse.org-architecture-council] Eclipse Council        Meetings        Annoucement

Yes, I can attend 4/27.

Bjorn Freeman-Benson <bjorn.freeman-benson@xxxxxxxxxxx>
Sent by: eclipse.org-architecture-council-bounces@xxxxxxxxxxx

03/29/2005 12:31 PM

Please respond to
"eclipse.org-architecture-council"

To	eclipse.org-architecture-council@xxxxxxxxxxx, eclipse.org-requirements-council@xxxxxxxxxxx, eclipse.org-planning-council@xxxxxxxxxxx
cc
Subject	[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

_______________________________________________
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council
_______________________________________________
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council