Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[eclipse-dev] Eclipse 3.4 retrospect

Thanks much for the retrospect feedback. You will find below a digest of the PMC thinking for addressing the issues, together with a suggested schedule.
This is going to be discussed in today's arch call.

- Philippe



- Performance:
        M7 is dedicated to performance again, plus continuous watch on performance thanks to Frederic
        Improvements to be made to perf test framework (better visualization and assessment)
        By M2, teams should revisit their performance results from 3.4 to figure action items (before it is too late again)

- Polish:
        M7 is also dedicated to polish. Need a dynamic team.

- Testing:
        All teams must be testing. If some tests are not automated, then smoke testing is mandatory for all teams. Smoke test plans to be posted by M2.
        In particular, all reference platforms *must* be tested by ourselves.
        All teams must be self-hosting too (not a replacement for smoke testing, but complementary)

- Feature work:
        Need better staging of feature work. Major items should go first due to ripple.
        By M2, all feature work should be accounted in plans, and properly staged (before M5). Ramifications in dependent layers need to be identified, and
        adoption should be staged accordingly.
        Beyond M5, PMC permission is required for significant feature work.

- Documentation:
        Should try to update the doc on the fly (not including screenshot) to avoid pain in the end, and lack of motivation; e.g. updating help context ids, F1 help text, and related tasks

- Process:
        Avoid late IP data collecting stress, use automatic IP instead
        It doesn't make sense to maintain platform-cvs-dev mailing list, platform-team-dev is enough
        PMC need to remind the schedule and rules in planning notes for making the entire team more aware
        No consumption of HEAD material as part of releng build script (use previous milestone strictly)
        Need to make build result pages better reflect presence of performance results


M1 - August 8, 2008 (6 weeks)
        focus on critical issues to backport to 3.4.1
        experimental work

M2 - September 19, 2008 (6 weeks) - PLANNING
        all teams have their release dev plan fleshed out, with proper staging of feature work (per milestone)
        all teams have assess their performance status: reviewed their performance results *and* identified areas for improvements, and planned major perf work (which is too big for addressing late in M7)
        all teams have reviewed their documentation state, and planned actions for it
        all teams have posted their smoke test plans, and assessed their level of test coverage (and planned for reducing addressing gaps)

M3 - October 31, 2008 (6 weeks) - DEV
        graduation plans for components from incubators are defined, paperwork/CQ etc initiated with foundation
        test coverage items actionned, automated builds provide test coverage assessment

M4 - December 12, 2008 (6 weeks) - DEV
        focus on critical issues to backport to 3.4.2

M5 - January 30, 2009 (7 weeks) - MAJOR FEATURE WORK COMPLETED

M6 - March 13, 2009 (6 weeks) - API FREEZE, FEATURE TUNING, I18N & ACCESSIBILITY
        finalized paperwork/CQ with foundation
(EclipseCon March 23-27)

M7 - May 1st, 2009 (7 weeks) - PERFORMANCE & POLISH, BEST EFFORT ON DOC
        all tests must be green or accounted properly (still failure)
        polish effort carried by dynamic team

RC1 (2 weeks) - May 15, 2009

RC2 (1 week) - May 22, 2009

RC3 (1 week) - May 29, 2009

RC4 (1 week) - June 5, 2009


Sauf indication contraire ci-dessus:/ Unless stated otherwise above:
Compagnie IBM France
Siège Social : Tour Descartes, 2, avenue Gambetta, La Défense 5, 92400 Courbevoie
RCS Nanterre 552 118 465
Forme Sociale : S.A.S.
Capital Social : 542.737.118 euros
SIREN/SIRET : 552 118 465 02430

Back to the top