Skip to main content
Jump to: navigation, search

Planning Council/June 02 2010


Meeting Title: Planning Council Conference Call
Date & Time: Wednesday, June 02, 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

Chris Aniszczyk Technology (PMC) N
John Arthorne Eclipse (PMC) Y
Oliver Cole Tptp (PMC) Y
Brian Payton Datatools (PMC) R
Doug Gaff ??? Dsdp (PMC)
Anthony Hunter Tools (PMC) Y
Oisin Hurley Stp (PMC) N
Ed Merks Modeling (PMC) Y
Thomas Watson Rt (PMC) Y
David Williams WTP (PMC) (appointed Chair) Y
Gary Xue Birt (PMC) Y

Strategic Reps

Cedric Brun OBEO (Strategic Developer) Y
Stefan Daume Cloudsmith Inc.(Strategic Developer) N
Neil Hauge Oracle (Strategic Developer) Y
Kaloyan Raev SAP AG (Strategic Developer) R
Markus Knauer Innoopract (Strategic Developer) R - travelling
Christian Kurzke Motorola (Strategic Developer) N


Wayne Beaton Eclipse Foundation (appointed) Y

Note: feel free to correct any errors/omissions in above attendance record.
Y = Yes, attended
N = No, did not
R = regrets sent ahead of time


 ? Nokia (Strategic Developer) X
 ? CA Inc. (Strategic Consumer) X
 ? brox IT-Solutions GmbH (Strategic Developer) X

Note: "Inactive" refers to Strategic Members we have not heard from in a year or so, and have been unable to convince to participate. Those members can become active again at any time. Contact David Williams if questions.


Next Year's Name

Should we do over? (Just kidding)

Indigo it is

Who will lead the Planning Council next year?

And the winner is ... myself (David Williams) to continue in this role.

Helios Release

Post RC4 exception process?
Question from John:

According to our schedule there is one more week of potential builds after RC4, labeled "Helios Final". I see on the planning wiki that it says, "only emergency fixes for very serious regressions will be considered." I can't remember if we discussed this in the past, but what exactly does that mean? Does it mean the release train exception process should be used, with changes announced in advance and require approval from others? Or, will this be left to the discretion of each project? Unless we've already covered this, we should probably decide on that soon. Note, the Eclipse TLP doesn't plan on any contributions after RC4 at the moment, but I just want to know the process in advance in case something comes up...


Autobuilds turned off
Exceptions, requests for rebuilds can be made to cross-project-dev list (no need for Planning Council list).
if fairly obvious, dw will trigger the rebuild (hm, can/should security be changed on that hudson job?)
or if doubt, dw will ask for further review/discussion with PC or PMC
there is a risk, since our setup depends on individual project repositories, that someone may "break the build", that is unrelated to original respin request
so all projects need to use care, and make sure nothing changes during this time
Let's review compliance:
Top Level
Flat view
Any to kick off the train?
Any gold stars to hand out?
Andrew Overholt and the Linux Tools Project is a shining example of joining the train well!

Maintenance Schedule

Fourth Friday of September? 9/24/2010

Fourth Friday of February? 2/25/2011

Next Year's Schedule

Not ready to discuss details, but the problems with +1, +2, +3 category (and short times) should be well discussed.

Similarly, Oliver brought up issue with need for better "warm-up" rhythm, especially if a prereq project is late. (EMF's "last minute" M6 delivery added pressure to TPTP's ability to build/test in time). No specific actions, process or remedies are known, but ... maybe a reminder to cross-project list that intermediate or warm-up builds are good (especially if going to be near deadline).

Cross-Project Teams


Planning Council/Cross Project Teams/Aggregation

Any issues moving to new b3 Aggregator? bug 312645

Should be produce hybrid p2/maven repo? bug 312656

Other business

  • Process for exceptions like "breaking API change after M6"
projects making the change should announce on cross-project
the team that discovers it, has a responsibility to report is as a "breaking API change" (don't just swallow it)
it might have been an accident or oversight and can be repaired for others
even if not (even if it really is required) it is a good way to document the issue so others know about it.
  • Should we have a combined/joint "migration guide" for all Helios projects? A central jump-off point?

ToDo Items

Next Meeting

July 7. Have our yearly "feedback" session.


Helios Simultaneous Release

Planning Council Members

Simultaneous Release Roles and Simultaneous Release Roles/EMO

Back to the top