Planning Council/Kepler retrospective

Kepler Planning Council retrospective

These notes were collected at the end of the Kepler Release, specifically just to collect them. And not to solve issues, or even necessarily to suggest solutions, but just to capture issues (good and bad) while the release was still fresh on our minds. Where solutions are suggested below, it is intended to primarily better capture the issue discussed .. not to dictate a or pre-judge a solution. Action plans and solutions will be discussed later.

History

Kepler is the eigth simultaneous release, following Callisto, Europa, Ganymede, Galileo, Helios, Indigo, Juno. The Planning Council meets regularly to come up with plans and requirements. Eclipse Foundation projects can voluntarily join the simultaneous release. For meeting minutes, see http://wiki.eclipse.org/Planning_Council.

Comments from PC meeting

These rough notes were captured from the "brainstorming" session. We will refine in future meetings.

Positive things mentioned

• Nothing specific was named, that wasn't named in previous retrospectives -- that is, all the positive aspects of participating and producing still apply.

Things that could have been better

• One issue discussed at at number of meetings was that "disabling everyone in M1" (in at effort to get positive confirmation of participation) seemed to cause a lot of extra work for everyone. The action taken was to get projects to send note to "cross-project" stating their intent ... so projects will not be disabled unless not heard from until after M3. bug 418432

• It was felt the strict rule about "releasing one month" before a service release was too strict (not enough flexibility, especially for new projects, making rapid changes and "releasing the tip". Thus, this policy was loosened a little to have released by RC1 (technically, to have release materials ready by RC1 and be feature complete).

• one new concern was brought up: That "release engineering" is not a very "diverse team" (Markus and David) ... and the concern was "what do we do if they stop doing it". While no one volunteered to help :) it was taken as a valid point to document. Briefly discussed "getting help from Eclipse Foundation", but at same time we wanted it to remain a "community driven" activity in general ... that is, those that have a vested interest in producing and consuming the release should be "in charge" ... and not become a "corporate activity". But, perhaps there could be some help with tools, and similar from Eclipse Foundation? Should b3 aggregator or EPP build become part of "CBI project"? At a minimum, need to make sure some of the process and mechanics are well documented so others could "take over" when necessary.

Reference

See also last year's retrospective