|[eclipse.org-planning-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.htmlhttp://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 ontheir 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 definethe "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 projectshttp://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
Back to the top