[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[eclipse-dev] Eclipse 3.4 retrospect (take 2)


After deliberation at the arch call, here is the revised retrospect data.

==================

ACTIONS:

- 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.
        By M2, polish items requiring major work are identified, and planned for properly

- 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 in 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 (http://wiki.eclipse.org/Development_Resources/Automatic_IP_Log#Contributors)
        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, 3.5 planned will be also made more explicit about expectations for each milestone
        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


SUGGESTED SCHEDULE:

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

>>>  (3.4.1/Ganymede-SR1 +0 dates:  RC1-September 1, RC2-September 8, RC3-September 15)

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)
        all teams have identified major work items for polish, and planned actions for it

M3 - October 31, 2008 (6 weeks) - DEV
        normal development
        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
        normal development

M5 - January 30, 2009 (7 weeks) - MAJOR FEATURE WORK COMPLETED
        normal development
        focus on critical issues to backport to 3.4.2

>>>  (3.4.2/Ganymede-SR2 +0 dates:  RC1-February 2, RC2-February 9, RC3-February 16)

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

M7 - May 1st, 2009 (7 weeks) - PERFORMANCE & POLISH, BEST EFFORT ON DOC
        all performed tests must be green or accounted properly (but then it is still a failure; i.e. it should have been compensated for elsewhere)
        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

Final (1 week) - June 12, 2009 - NO CONTRIBUTION UNLESS ABSOLUTELY CRITICAL



















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



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