Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[eclipse-dev] Planning Meeting Notes Nov. 20, 2002

*** Outreach stuff ***

Erich did a talk at JavaPolis
- 700 people
- talked about JUnit and use in Eclipse
- people really liked it.

*** Postmortem on M3 ***

Text/JDT Text:
- went well in general
- one PR needed to be fixed because of potential loss of data, which led to
late submission
- lost a couple of days to unanticipated work on a memory leak in the
larger JDT UI space

- editor management effort was too ambitious to get in for M3 (work planned
for M4)
- key bindings in, but still some work in M4.
- got decorator and menu update performance improvements in for M3

Rel Eng:
- dragged on to Saturday morning :-(
- Q: are the test passes working in the current format?
- four restarts of the build near the end
- testing on the afternoon of the build helped solve some of the timezone

- too ambitious to attempt to get all Mac work done for M3
- had to basically put the M1 version (plus some fixes) back in HEAD and
switch to working on the new code in a branch
- new code is getting close now, though
- otherwise, things were fine

Aside: SWT team had to respond to several changes released by other teams
on the weekend and monday before the M3 build.
- all Mac development by SWT team is self-hosted
- SWT team was running nightly builds successfully right up until the
monday before the M3 build
- *all* teams should test on Mac

- two competing goals: want milestones to be lightweight, but need to have
product be stable for users
- also want milestones to be real goals so users can rely on features
showing up -- dates are important
- means there is some stress around each milestone, but prevents massive
pain at the end.
- (note: work can proceed across milestones, as long as it is not released
into head.)
- resolution: use same process for M4, but need to be aware of the problem
of releasing stuff at the very end (also, all teams should test on *all*

- confusion caused at the end because of miscommunication issue with UI
team w.r.t. responding to new schemas which were planned to be released
post M3, but went in before
- F1 enablement work was done, but nearly didn't get it in because of a
problem with version/releasing the project
- mixed feelings about current milestone length: recognize that it reduces
pain at the end but increases stress when attempting larger features

- time lost to travel: OOPSLA
- editor team had to help out with some UI work
- still pleased with what went in

*** Looking to M4 ***

The focus for M4 is performance:
- Starting a performance dynamic team with contacts from all teams.
- Want to get started quickly: should have first set of problems to look at
(say, 2 per team) by end of this week.
- Performance issues should be identified by bug reports with the
"performance" keyword and M4 as the milestone
- Remember: performance varies significantly between platforms (UI,
network, disk, etc.), so need to test on all.
- Also need to look at scaling issues, since some user products are
significantly larger than base eclipse
- Any tools which teams have written to identify performance issues should
be made available to all users
- Performance should be considered to be higher priority than other
features for M4.
- Poor performance is a BUG.
- Teams should write benchmark JUnit tests.

Should have team M4 plans posted on web by end of week.

Back to the top