Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Planning Council/August 04 2010
|Meeting Title:||Planning Council Conference Call|
|Date & Time:||Wednesday, August 04, 2010, at 1600 UTC / 1200 Eastern|
|Dial-in:||For the call-in numbers, see the "Project Review" number on Foundation Portal page.|
PMC (and Strategic) Reps
Soon to switch to b3 aggregator format files. bug 312645
Warm up (RC1) builds to start soon (8/9 to 8/13).
SR1 Fourth Friday of September 9/24/2010
SR2 Fourth Friday of February 2/25/2011
For detailed RC schedules, see Service Release Schedule in master plan
Indigo Plan and Schedule
Tracking "setup" required from Foundation in bug 321522
See initial Indigo Wiki page
Are we agreed to Indigo dates ? All shifted by one calendar day (to keep same day of week). Can we say these are official?
Issues and Proposal for 3.7 versus 4.1
For planning documents, etc. we'll call 3.7 based work Indigo Minor, and 4.1 based work Indigo Major.
For this plan, more so than previous years, there will need to be adjustments based on experience over next few months.
Ideally focus would be on 4.1 based work. But final plans need to be based on where projects want to focus, and what proves suitable.
Main goal: participating projects must work with or contribute to both platform levels.
There's several options to accomplish this -- and participating projects must explicitly state what their plans are, what they support.
- One set of plugins work with both versions.
- Projects contribute "maintenance only" to Indigo Minor, but branch and all new work done assumes Indigo Major
EPP Packages: Ideally, EPP packages would be based on 4.1 (only). If experience shows 4.1 is not ready, or if projects can not fully move to 4.1, then this needs to be dropped back to 3.7 (only). Is is possible that each "package owner" can decide which they want. [Would this make sense?] Is is a fair assumption to say its unreasonable to produce two sets of packages? (I think so, but others can answer too).
Issue: Can all bundles reside in one repo, and correct ones "pulled out" by P2? (can this be done easily, and reliably, that is).
Issue: If focus is on one stack, how to "test" other stack?
Feedback required from large projects such as webtools, CDT
Issues raised in meeting:
- Branding. Is it really one simultaneous release? Or two? Is one name (Indigo) enough? Does Indigo Major and Indigo Minor suffice? Or, do we need a whole additional code name?
- Provisioning? Often adopters provide an "all in one" product package, but they also want to "install into existing installation". So, what/how can they "install into". How to document and explain to users and customers?
- Its one thing to conceive of one different "platform" in stack, but if or when there are different versions at higher levels, seems to get very complicated (e.g. if JDT has an Indigo Major vs. Indigo Minor version, that might "force" projects to take different planning paths. Its unclear what their plans are, and if the e4 related function would be "additive" to Indigo Minor bundles, or complete replacements.
- Need another meeting in a few weeks to make progress on this issue.
August 18, 12 noon (Eastern) September 1, 12 noon (Eastern)