Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Eclipse/Helios/Retrospective
< Eclipse
See also Eclipse/Galileo/Retrospective
Pluses
- Less drama than in 3.5
- Dates (milestones, RCs) worked well
- Bugzilla performance is much better
- CVS problems have been fixed
- Help from Frederic with performance is appreciated
- Thank you to John for continually keeping the plan up to date
- Early freeze for big features in M5 helped downstream teams adopt those new features
- Integration builds worked better than last year
- Impressed by what we accomplished when looking at N&N document
- Performance bugs opened by Frederic were dealt with promptly. Thanks!
- API tools worked better than before
- Liked the changes to splash screen for different milestones
- Release train started building with M1 this year, and hit every single milestone on time
- A few cases of last minute scrambles but no amount of planning can completely eliminate that
- This suggests our milestone end-game schedule is about right.
Minuses
- Two day test pass against RC2 too late ⇒ should be earlier, e.g. after M7/RC0
- Teams forgot I build submissions, this should not happen
- Polish wiki page and its intent was not know to everybody ⇒ announce to bigger audience and explain its intention in the wiki
- By comparing to the baseline, we don't catch cases where performance improvements are lost due to later regressions in the same development cycle
- Wiki pages are a pain to search (you are better off using Google search to find anything in there)
- Documentation not good enough (McQ: it's a tradeoff between doc vs. dev, you have to plan and allocate time for documentation)
- PDE had some slippage of feature work: import from cvs and feature-based launch
- Features added late never get enough polish
- Too many bugs with target milestone slipping
- Better to not set than to keep slipping, or just set with "3.7" and only give a specific milestone when you are confident you will be able to work on it
- This happens more often with part time committers who aren't always able to schedule in advance how much time they will have to work on Eclipse. (This is an acceptable tradeoff to getting more committers)
- Copyright updates were done too late, and introduced some significant regressions that we didn't have time to discover through testing
- This must be done earlier: better to have a few files with stale copyright than to risk the release quality
Ideas and comments
- We should point out cases where performance improvements have been made (rather than only focusing on regressions)
- Would be good to have someone analog to Frederic but focusing on overall Eclipse user experience
- JDT Core team lost too many members in too short a time period
- Do we need more internal documentation to help with team transitions? (Up to the component leads to ensure this!)
- Please make sure you move bugs that are misfiled to other components in a timely fashion.
- Should we have more point releases (more frequently?)
- Might be a good idea to test the EPP packages mid-milestone to avoid late breaking bugs later on in the release.
- Need to allocate time to make our project web sites more attractive