[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[eclipse.org-planning-council] DRAFT Minutes for comments
|
Planning Council members,
Thanks for the productive meeting last week here in (now sunny)
Portland. I attach the draft minutes for your review before I post them
on the website. Let me know if you have any comments, corrections,
additions, clarifications, quantifications, humor, and even facts to add.
--
*Bjorn Freeman-Benson*
Technical Director, Open Source Process and Infrastructure
<http://eclipse-projects.blogspot.com/>
Eclipse Foundation <http://www.eclipse.org/>
voice: 971-327-7323 (PDT, UTC-7
<http://www.timeanddate.com/worldclock/custom.html?cities=202,188,195>)
email: bjorn.freeman-benson@xxxxxxxxxxx
<mailto:bjorn.freeman-benson@xxxxxxxxxxx>
Title: Eclipse Planning Council Minutes
Eclipse Planning Council Minutes
May 19, 2005, Portland, Oregon
Present |
|
Regrets |
Paul Clenahan, Actuate
John Duimovich, IBM Corporation
Bjorn Freeman-Benson, Eclipse
Doug Gaff, Wind River
Richard Gronback, Borland
Kevin Haaland, IBM Corporation
|
Georg Lenz, SAP
Mike Milinkovich, Eclipse
Mike Norman, Scapa Technology
James Saliba, Computer Associates
Tyler Thessin, Intel
Tim Wagner, BEA |
|
John Graham, Sybase |
Minutes / Discussion Items
(these notes are in logical rather than
chronological order)
Participation In Reviews
We discussed the Eclipse Quality issues that the other councils had discussed
the previous two days. There are not many notes on this as the issues had been
discussed at some length previously. The only item of note was that the idea of
proposals should have Champions was brought up and discussed - no definitive
conclusion was reached.
IP Policy
Tim Wager (WTP) brought up the concern that the EMO was not keeping up with
the IP reviews and that because WTP was only one milestone away from release
0.7, there does not appear to be enough time to complete the reviews. Mike
explained that this is a temporary problem of the EMO dealing with the backlog
of needing to re-review all the contributions to date. Mike expects the EMO to
be caught up to real-time by the end of 2005. In the meantime, bring any looming
deadlines to Mike's attention.
Project Infrastructure at the Foundation
A number of the projects had asked for virtual servers at the
Foundation, but it turns out there are technical problems that prevent that from
working easily. And the Foundation's rack does not have enough space to host
inexpensive 1U servers for each project. The temporary solution is for top-level
projects to host their extra services elsewhere and use redirects to appear to
be part of the eclipse.org infrastructure. For example, eclipse.org/services
is hosted off-site.
Planning, Information, and Synchronized Releases
The Requirements Council has expressed a requirement that the major projects
have synchronized releases; where synchronized means "ship on the same
day". The Requirements Council did not want to require synchronized version
numbers because that would eliminate the semantic meaning of version numbers.
There is a need to communicate which version of each project works with which
other version both upstream and downstream. The upstream compatibility is
handled automatically by the Update Manager, although it would be nice to have a
documentation version of that same information. But the downstream
compatibility is not described - if I have version X of project Y, what version
of project Q can I successful use?
We agreed that synchronized releases would be driven by the Platform releases
- a "release train", if you will - and that there would be one train
per year. Projects may release more often of course, but should have a release
that joins the train as well. A project that is having internal trouble
synchronizing can opt-out and ship later, but if the same project is having
troubles due to an underlying train framework (such as something in Platform)
will cause the whole train to slip its release.
All of this is opt-in, but the expectation is that all the major
projects will opt-in. Opting-in is a significant commitment by the projects and
it includes:
- Always using the latest milestone, better yet the latest integration,
builds of all the underlying projects.
- Provide distributed smoke tests so that the community is not dependent on
the project teams to test the integration compatibility.
- John W or Kevin H (Platform) will host train phone calls starting after
the Platform defines its release schedule. The Platform expects to commit to
a 3.2 schedule before the August council meetings.
- The projects will allow formally announce their opt-in status on their
websites and possibly on some sort of more global release train status
page.
- Other commitments to be announced.
ACTION: Kevin H will come to the
August Planning Council meeting with the mechanics of what projects are
opting-in to; and at the August meeting the project will opt-in or not.
Status Report Format
We discussed the .dates.txt
prototype that Bjorn had put together and decided to switch to an XML file. The
XML file will take the place of the static HTML quarterly status executive
summaries. This file will have all the current summary information as well as:
- What is the version lineup that works on the last major train?
- What is the version lineup that works on the current HEAD train?
- The project leaders section was vague and will be clarified.
- The shipping releases section should be automatically gathered.
- The project description should be taken from the website automatically.
- The executive summary paragraphs are the most important.
- Dependency information
- Perhaps include a list of the third-party libraries and code that is
included in the release.
- One page maximum on the printer - the goal is to be able to print out a
sheaf of these and read through them on an airplane trip.
ACTION: Bjorn FB will write some
tools that process these XML status reports: collate them for the website; build
the timeline of releases; send reminders to project leaders who have not updated
their status; etc.
Website Content
We discussed who the Eclipse.org website has a lot of woefully out-of-date,
and perhaps even wrong, pages lying around. We agreed that we need to have
either good information or no information, but we cannot tolerate bad data.
ACTION: Everyone agreed to freshen
their content, either by (the best choice) making it good or (second choice)
removing all the obsolete and incorrect pages. Everyone agreed to do so by one
month after the Platform 3.1 release ships, if not before.
Notes taken and posted by Bjorn Freeman-Benson