Eclipse Planning Council Minutes
June 20, 2007, Boston, Massachutes
Note that the attendance list is not accurate at this time.
Gary Xue, Doug Gaff, Rich Gronback, David Williams, Philippe Mulet, Oisin
Hurley, John Graham, Bjorn Freeman-Benson, Oliver Cole, Walter Harley.
Minutes / Discussion Items
Europa Simultaneous Maintenance Releases
We decided on September 28th and February 29th for the Fall and Winter
maintenance releases. Mondays (Sep 24, Feb 25) will be the +0 dates; Wednesdays
(Sep 26, Feb 27) will be the +1 dates; and Fridays (Sep 28, Feb 29) will be the
EclipseCon 2008 Tracks
Discussion led by Doug Gaff, EclipseCon 2008 Program Chair. These notes are a
bit of a stream of consciousness mish-mash:
- Long talks and demos are the same thing.
- Ideas for keynotes? Ask everyone, perhaps even blog about it.
- Decide on real beginning and end dates to the conference and not send
email blasts until those are set because people use those to make travel
plans and then if additional things get added to the beginning or end, those
non-refundable plans become invalid.
- Recruiting on sponsorships for mobile to match Doug's emphasis.
- Tracks into five Europa categories (or something like that) on the
- Audience: people think that it's less of a committer conference and more
of a user conference. Perhaps it's a "I'm a committer on X, but a user
of Y and Z" conference.
- Program Committee calls - once a month.
- Make the number of slots page be hidden/PC-only because it led to
submitters thinking they were extra slots or no slots or whatever when the
PC really reallocates things as necessary.
- "X for Existing Committers" track.
- "Tips & Tricks for Users" track / "The Missing
- Separate pre-reqs box on the submission page and have some examples. Or
the audience: "this is for people who are interested in using X and
already know Y".
- Explicitly ask the submitters to explain how their talk relates to open
- Suggest to sponsored talks that they should talk about "how we built
on top of Eclipse; here are the frameworks", not just "we are on
top of Eclipse and we're a product". We them them "in our
experience, this kind of talk works well at EclipseCon..."
- Use bugzilla dependencies to define an ordering for the talks.
- Reduce the tutorial price at the cost of increasing the base price: $300
(maybe $400) is the consensus. Especially if the tutorials are combined
throughout the week.
- Encourage tutorial presenters to submit short tutorials only. Sequences of
of short tutorials if necessary, but not long tutorials.
- BOFs that don't end, i.e., do not schedule two BOFs per room per evening.
The PC should be part of the BOF selection process.
- The Planning Council wants a Monday-Thursday conference, not a
Sunday-Wednesday one. And they want to combine the tutorials with the rest
of the conference.
Europa Retrospective; Ganymede Thoughts
We discussed our success (and issues) with the Europa Simultaneous Release
and what we'd like to have for Ganymede next year.
- Europa-matic on workstations would
be great. Bjorn agreed and intends to have the Gan-omatic available
- A suggestion that for Ganymede, we
change from +1 and +2 to "as early as you can". The milestone
builds should be more incremental with projects releasing at multiple times
and then having a cut-ff date that defines the milestone.
- Platform APIs were frozen by the time the Europa M4 was just starting.
Conclusion: we need to start with a Ganymede M1 to get everyone working
together sooner. Basically, Ganymede starts now/soon and will continue
throughout the year.
- Philippe will provide the Platform milestone dates by the end of July
2007 so that we can define the Ganymede M-dates.
- Post-note from Bjorn: I imagine that the "must dos" and
"should dos" will be discussed prior to our next face-to-face
and then decided upon at that meeting.
- It is essential for dependent projects to pay attention to their upstream
projects so that API changes can be requested, used, tested, etc. before the
last minute. The last minute is bad.
- Post-note from David: perhaps we need
a better designated time to do "full install" testing.
Currently it's assumed to do "as we go", but that's
hard to do. Perhaps for one week after each Ganymede milestone, request
projects do some "report"?
- There was disappointment amongst
some Council members and EMO staff that the Europa requirements were relaxed
over the course of the project. For Ganymede, we are considering having a
two tier simultaneous release:
- Tier 1 - meets all the requirements (packing, signing, user interface
- Tier 2 - will release at the same time, but does not meet all the
- Obviously the Tier 1 projects would get the quid pro quo: priority on
IP reviews, better service from the build-meister, etc.
- That brought up a discussion of what is the value proposition of the
requirements? If there is a clear value proposition, then projects
will implement them; if not, then projects will not spend as much time on
them (realistically). We should be clearer on what is really a requirement
versus what is just a really, really good idea.
- We should stop threatening to kick projects off because we realistically
won't do it. The only time we might do this is with incubation projects and
then it's really the PMC's responsibility to convince them to withdraw.
- Although, post-note, the
Executive Director made it clear that he has the power to kick projects
off the release train and he will take that action if necessary to
preserve the overall quality of the Eclipse frameworks and eco-system.
- There was a discussion about the purpose of Ganymede - is it a product? In
the end, we concluded that the point of Ganymede was to produce "the
CD" with all the project on it. The purpose was not "providing a
better integrated product".
- Ganymede is more of a process
rather than a technical solution: it's a reliable release stream for
commercial product planning. Not sure if we need to change
much from Europa except maybe a better understanding of all the project
dependences - Europa has gone well in terms of reliable milestone builds.
- Other noble goals, like "improved user experience" were seen as
requiring a lot of extra work and perhaps "near impossible" given
that there is no one person in charge of the overall user experience.
- We like the EPP packages and the role-based downloads; role-based
downloads are better than the "everything is available in the update
manager" distro. We should work with the EPP project to consume the
Ganymede builds automatically - start by pulling them into the Planning
- We had a discussion about recognizing Europa bugs. We came to the
- Use cross-project keyword instead of Europa or
some other keyword.
- The meaning of this keyword is "the Planning Council will look at
bugs with this keyword"
- The query for these bugs is for facilitating conversations around
these cross-project bugs.
- These bugs are "bug exists if N projects are loaded, but does not
exist if just one project is loaded"
- The idea of requiring conformance to the UI Best Practices Working Group
guidelines was brought up. We decided that if the group produced some
guidelines in time for them to have an effect on Ganymede, we would consider
- Should we do full source builds of all Ganymede projects? Maybe, maybe
not. Source building would identify more API change issues, etc., but it
would require projects to change their ways to have more common
infrastructure. And the source build would be broken a lot of time. Maybe we
should do something like more distributed testing instead.
- Should we have some kind of CPAN-like distributed testing system? There
was some fear that this would be a lot of work, but given how well it works
for other open source projects, it seems like a good idea to investigate.
- We also discussed how we could ensure API cleanliness. Each project can
control the issue in their own code, but if they rely on other projects and
those projects do not adhere to the same level of cleanliness, that can put
your project at risk and make it fragile. Source level builds would help
with this, but perhaps what is really needed is a tool that makes this
problem visible to everyone. The Platform team is considering working on
such a tool; the WTP team has some tools already; someone mentioned that
there might be something on alpahworks...
- A good first step is that each project needs to publish or expose their
cross-project access rule violations. Better would be to include all API
violations including the semantic ones that we can't capture in access rules
yet (e.g., "don't instantiate this class" and "not all public
methods are API methods"). The next step would be for us to investigate
- The Eclipse Top-Level Project is planning to split development streams:
3.x verus 4.0. Philippe asked for feedback from the other leads about the
impacts on them - general consensus was that this was a good thing. The 3.x
stream will be about consolidation and productization of the existing 3.x
code base; the 4.0 stream will be a longer term effort: two or three years.
- And final topic in this section was about performance and scalability and
how to generate a better understanding of these issues amongst the projects.
How are projects measuring their performance and scaling metrics? Are they
measuring them at all? The Platform, WTP, and BIRT had performance tests,
but none of the leads were really happy with the tests that they have...
Phillipe said the Platform needs to be able to handle 10,000 plug-ins and
that all projects should handle huge workspaces, etc. The Platform team used
M7 as a "performance iteration", but none of the other projects
did that. Consensus was that
Ganymede should recommend, or maybe require, that M7 be a performance
- Each project on the train needs to do performance and scalability/resource
usage testing. Maybe use the TPTP tools?
Eclipse IP Process/Policy Improvements
We discussed our difficulties with the Eclipse IP Process and discussed the
following issues that we will take to the Board meeting tomorrow:
- Committers should be able to committer greater than N LOC and not be
limited to 250 LOC. For example, the approval for the NEC contribution to
DTP 1.5 occurred so late in the development cycle that they were not able to
integrate and develop the contribution as much as possible.
- Keeping up with external run-times is a (future?) problem for STP. For
example, Apache CXF 1.0 was not robust and the CXF project is moving towards
2.0, but their timing is outside the Europa window, so STP needs to use a
milestone level build of CXF but the Eclipse Legal process will not consider
milestone level builds. Perhaps a "holding pen" for not
completely reviewed libraries?
- DSDP wants a holding pen for GPL-based libraries: RXTX and gdb.
- IP review takes too long. When pressed on what "too long" means,
the consensus is "one or two weeks is acceptable; longer is not".
The Ant 1.7 and Jcraft 1.3.1 examples were brought up. The team would like
to see a fast track for service releases.
- Eclipse Legal needs to provide an ETA if the ETA is greater than 1-2
weeks. Having Legal say "I can't give you a date" is not
acceptable - if we (the project leads) have to stick to dates, then they
have to as well. There are many standard project management techniques that
could be applied, including estimates based on historical trends and
characteristics of the request.
- We would like to use the Parallel IP process for all projects.
- The Foundation should provide Black Duck (or whatever software the
Foundation is using to scan contributions) to the project leads so that the
project leads can pre-scan all the contributions to help speed things along.
- Rewrite the Legal documentation from the POV of developers not the POV of
- Other issues include the QVT University of Kent OCL library: it was
rewritten faster (months of work) before Legal even started to review it;
and accessing/depending on third-party libraries that are not distributed
with the Eclipse project (the Buckminster-Maven-SVN example).
- Post-note from David: "There were
some constructive suggestions that came out of it, but I still think it's
working fairly well, and, as human nature is, any discussion of
"how to improve" ignores the enormous improvements that have been
made. (I recall when 'approval' was not even traceable!)"
Notes taken and posted by Bjorn Freeman-Benson