Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Planning Council/April 10 2013
Contents
Logistics
| Meeting Title: | Planning Council Conference Call |
| Date & Time: | Wednesday, April 10, 2013, at 1300 Eastern |
| Dial in: | (See Asterisk service for complete details on SIP, potential new numbers, phone mute commands, etc.)
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
Kepler
M7
- Issues?
- No issues raised
EclipseCon face-to-face follow-through
- Continue discussion from EclipseCon face-to-face
- Come up with actionable items
- Solicit volunteers to do the actions
- The following are notes/actions from discussing the specific items.
Policy on new releases joining SR
dw to update current policy in FAQ with the additional detail.
Build reproducibility
dw to come up with "perfect example". Add to wiki, send to Wayne and Than, and see if some way "CBI" maven task could produce, from template, as part of build output.
dw better educate. Give perfect example on wiki. Emphasize non-changing repos. Give "acceptable" example on wiki. Give "unacceptable" examples on wiki.
dw create "report of changes" from one build to another, one repo to another, so a) individual projects could see if things changed when they should not have; b) PMCs, Team Leads, Planning council could better observe "big picture" of how much change there was, especially related to changes in build input files.
dw start to tag build file project, each build (so we could diff build files).
wayne to add item to release review that "there must be a retention policy" (it should cover how long repos stay around, such as milestone repos, and also via ?education? emphasis that it must be "non-changing".) And then Planning Council can add extra rules for sim. release, if necessary.
Release train rules
John and Neil volunteered to improve. The idea is to provide briefer version, but still (probably via hyperlinks?) allow readers to find out "reasons" for a rule. This would be for Luna (due in Fall, after Kepler release).
Release train rhythm
We don't anticipate any changes to rhythm, but perhaps more emphasis/education on milestones. (Perhaps, eventually, add idea of "1 milestone" to SR cycles).
Wayne volunteered to add suggestion/idea to GSOC database to make some user friendly way that users could say "I want to follow beta releases" ... this would add the "current" development stream URL to update sites, so they'd get updates from milestones, without having to know about it, and manually add it.
The release train and RT
No actions came from this discussion. It was thought that if/when RT projects begin to need coordination, that we are certainly open to changes in "rules" that make it more accommodating. (But ... we don't know if any concrete rules that are inhibitors (all can have exceptions) ... but the mere act of coordinating schedules, if there is no need to coordinate with others, is inhibiting). If RT stacks are all relatively independent of IDE, and each other, they often prefer to set their own schedules, etc. There might be a day when there could be some "marketing" advantage, say to announce large maven central update, or something, might be interesting to Rt projects ... but, not clear its needed now.
Orbit
The Orbit Project Lead (dw) agreed to a plan for a plan ... a plan will be created after Kepler release, by end of August (since July often a "slow" month) ... and implemented in the months after that.
Next Meeting
- May 1, 2013 - First Wednesday Meeting