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

Projects to send note to cross-project list. (How to handle "individual projects" vs. those that release as a "group", e.g. WTP?, Platform?)

Planning Council (or, Wayne) enters their "entry" and +n date in database.

Deadline? M4 seems "late" for those already in? We've said "once in, always in". Hence, how does this interact with "disabling in aggregation"?

General agreement, though some questions still to work out ...

Action items:

Wayne will send note to Cross-project "in a day or two". For Luna, he will start with initial data from b3aggrcon files that have had contributions enabled.

Wayne mentioned only two thirds of "last years projects" have responded to list ... so a) reps should remind their projects/PMCs to re-join explicitly (or, be explicit, if not) and b) Wayne will modify "participating projects" page to also list those that haven't said, yet.

DW to open 2 bugs:

1) What are best "deadlines", in relation to b3aggrcon files. The idea would be be something like "for those already in train, they would "stay enabled" until after M1", then if had not been heard from on cross-project list, they would be disabled. If not heard by end of M3, they would be removed (since M4 is deadline to be "in", even for new comers).

Done. See bug 418432. I actually changed my mind and put M2 as deadline, based on this year's experience that by M2, the previous year's maintenance release (SR1) should be done, so really little excuse after that, not to have announced and be planning next years release).

2) open (or find, and change priority of existing bug), that b3aggrcon files would be changed to conform to "project name" pattern.

How can (or should) we better capture what new features are in an SR for adopters awareness?

There was agreement "we needed something", but flexible on exactly what.

Doug took action item of working on wording of new policy for Planning Council consideration and approval ... it'd be something like "feature freeze by (and in) RC1 and Release Review Materials complete by RC1". Release Materials would include "new feature" descriptions for adopters, so that'd be covered.

First major releases not allowed. Projects must maintain backwards compatibility with the release.

Projects must follow the ramp down schedule for the SR. The bits for the release must be made available at RC1 and can not be introduced later than that. Bug fixes of course can be made during the release candidate cycle.

Release review material must be available to the community by RC1 to document the changes and new features in the release.

We will allow one month for members to review with projects and strategic members to be sure it "fits" with internal processes, etc, but seems reasonably balanced. This would replace or be incorporated into a rewrite of our current policy.

On going discussions

[Can we turn this into an action item, owned by someone? Otherwise, will remove from "on going discussion".]

Do we need, or how can we help enable, "more frequent releases"? Including what, exactly, that means. Such as, currently projects can release whenever they want, but the issue seemed to be on EPP packages and/or "prime real estate" of "Eclipse Foundations Downloads" page?

Decided we'd remove as "on going discussion" ... that we've done all we can as Planning Council ... but please raise topic again if projects/members have any concrete suggestions/concerns.

Kepler Retrospective

For both categories, it was felt most had "already been said" (in our on going meetings or previous retrospectives).

But 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.