Planning Council/October 2 2013
|Meeting Title:||Planning Council Conference Call|
|Date & Time:||Wednesday, October 2, 2013, at 1200 Noon Eastern|
|Dial in:|| (See Asterisk service for complete details on SIP, potential new numbers, phone mute commands, etc.)
Phone Numbers: (Check Asterisk/Numbers for more or current phone numbers.)
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
- Will re-start aggregation builds near end of year (unless requested earlier)
- 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.
- 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).
- 2) open (or find, and change priority of existing bug), that b3aggrcon files would be changed to conform to "project name" pattern.
- 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.
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?
Progress on Action Items
- Editing of "Requirements Document"? (Dani and Neil)
- GSoC project for "Development Channel"? (Wayne)
- 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)
- Complete Google Calendar. (dw)
- Compute Luna SR dates. (dw)
For reference, see Planning_Council/Juno_retrospective.
- what worked:
- what could be better:
- November 6, 2013 - Regular First Wednesday Meeting
- 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.