Difference between revisions of "Planning Council/October 2 2013"

Latest revision as of 13:25, 2 October 2013

Logistics

Members and Attendees

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.

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
D = delegated
X = not expected

Announcements

• EclipseCon 2014 Submission system is now open http://www.eclipsecon.org/na2014/cfp

Kepler SR2

• Will re-start aggregation builds near end of year (unless requested earlier)

Was suggested or requested to "leave enabled" and even build periodically, say, once a week, just to give opportunity for early testing for those that desire or need that.

Luna Planning

• Topics for possible discussion:

• Change policy on disabling all in M1 to require "actively joining"?

• Related to Wayne's proposal on new "how to join" method: http://dev.eclipse.org/mhonarc/lists/eclipse.org-planning-council/msg02190.html

Key aspects:

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.

Done. See bug 298259.

• Should we revisit the policy about "release one month prior to SR"?

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

Doug proposed this wording on mailing list:

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

Progress on Action Items

• Editing of "Requirements Document"? (Dani and Neil)
  • See current draft of proposed changes SimRel/Simultaneous_Release_Requirements_PROPOSED

Dani and Neil to update more in a couple of weeks and keep us posted on mailing list. The goal is to have "yay or nay" version by next meeting.

• GSoC project for "Development Channel"? (Wayne)

While GSoC is over, for a year, Wayne will at least recall history and open a bug for this..

• Improved "aggregator examples/doc". (dw -- no progress).
• [Orbit plan "by end of August". (dw -- no progress -- will likely be late, still "in October")]
• Need to improve Luna wiki page (dw) Done. Updated categories of "standard" documents. Updated some FAQs. Pointed "SimRel" to "Luna".
• Complete Google Calendar. (dw)
• Compute Luna SR dates. (dw)

Kepler Retrospective

For reference, see Planning_Council/Juno_retrospective.

• what worked:

• what could be better:

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.

Next Meeting

• November 6, 2013 - Regular First Wednesday Meeting

Reference

EclipseCon face-to-face follow-through action items. For original meeting notes, see Planning_Council/March_24_2013 and for discussion leading to action items, see Planning_Council/April_10_2013. For last status update, see Planning_Council/May_8_2013.

Luna Wiki page

Kepler Wiki page

Planning Council/Juno retrospective

Planning Council Members

Simultaneous Release Roles and Simultaneous Release Roles/EMO