Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Planning Council/August 05 2015"
m (Mars Planning -- modified proposal) |
(Mars Planning) |
||
| Line 154: | Line 154: | ||
* What to call September and February releases? | * What to call September and February releases? | ||
| − | :* Propose to change name to "Mars 1" and "Mars 2" to better reflect the rules that have been in place for years (See [[SimRel/Simultaneous_Release_Policy_FAQ| Policy FAQ]]), and perhaps name change alone would help correct the mis-perception that "new things can be added only once per year". For some recent history | + | :* Propose to change name to "Mars 1" and "Mars 2" to avoid the "service release" terminology, as one way to better reflect the rules that have been in place for years (See [[SimRel/Simultaneous_Release_Policy_FAQ| Policy FAQ]]), and perhaps name change alone would help correct the mis-perception that "new things can be added only once per year". For some recent history discussion, on how we ended up with "just a number", see [https://dev.eclipse.org/mhonarc/lists/eclipse.org-planning-council/msg02487.html mailing list thread] on the topic. |
| − | + | ||
: - Largest impact would be to change "MarsSRn" type phrases to simply "Marsn" in the few places it is used. | : - Largest impact would be to change "MarsSRn" type phrases to simply "Marsn" in the few places it is used. | ||
| − | : - When generic words are needed, instead of numbers, the June Simultaneous Release | + | : - When generic words are needed, instead of numbers, the June Simultaneous Release can be called "the initial yearly Simultaneous Release" and subsequent ones, when generic wording is needed can be called "subsequent release". For example, "Our project typically does XYZ in subsequent releases, not the initial release". [suggestions welcome ... not happy with that exact terminology, but, we should have something to suggest.] |
| − | : - The "Policy" (currently in Policy FAQ) will be "moved up" to the actual "plan" document. (Just as well move both items into the Plan, even if as footnotes. | + | : - This terminology applies primarily to the "Simultaneous Release". Individual projects should still refer to their releases as accurately as possible (service release, or minor release, if not specific number). |
| − | :: > In general, "the policy" will emphasize that new projects can join in subsequent, as well as initial releases and projects can contribute "minor releases" as well as "service releases" ... it is up to the project. But, a) | + | : * The "Policy" (currently in Policy FAQ) will be "moved up" to the actual "plan" document. (Just as well move both items into the Plan, even if as footnotes.) |
| − | : - We need to (also) add milestones for subsequent releases. I propose we have two milestones, M1 [not sure when, yet], and M2 become what we currently call the "warm-up RC". So, we would end up the 2 milestones, and 3 RC's. | + | :: > In general, "the policy" will emphasize that new projects can join in subsequent, as well as initial releases and projects can contribute "minor releases" as well as "service releases" ... it is up to the project. But, a) must be "backwards compatible" with that train (for example, a minor release that changes "internal methods" into API, should leave the "internal methods" in place, but deprecated) and b) almost never would be a "major release" -- the project would have to be a pure leaf component in Simultaneous Release, and have good reason to believe would not effect any adopters (hard to do, in practice), and would require "exception process" in Planning Council (partially as sanity check, but primarily to ensure well communicated). |
| − | :: > New Projects or features would have to be by M2 [Or, should we be stricter, and say M1? -- at least, for Neon?] | + | : - We need to (also) add milestones for subsequent releases. I propose we have two milestones, M1 [not sure when, yet], and M2 become what we currently call the "warm-up RC". So, we would end up the 2 milestones, and 3 RC's. The milestones are needed primarily for those new projects joining, or those adding large new features. But, as with mainline development, everyone should contribute "their latest", even if just working on service. |
| + | :: > New Projects or features would have to be in the aggregation build by M2 [Or, should we be stricter, and say M1? -- at least, for Neon's subsequent releases?] | ||
| + | :: > [TODO: More of a Neon Item, but consider having more than 2 streams being aggregated. Purpose would be to better enable projects to be working on Release+2 before everyone else is finished with Release+1 (for example).] | ||
== Neon Planning == | == Neon Planning == | ||
Revision as of 14:25, 19 July 2015
Contents
Logistics
| Meeting Title: | Planning Council Conference Call |
| Date & Time: | Wednesday, August 5, 2015, 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
Announcements
- ?
Previous meeting minutes
- Review previous meeting minutes if you'd like. That is, review them before meeting, but if questions or issues with previous minutes, this would be a good time to bring them up.
Mars Planning
- Any issues?
- What to call September and February releases?
- Propose to change name to "Mars 1" and "Mars 2" to avoid the "service release" terminology, as one way to better reflect the rules that have been in place for years (See Policy FAQ), and perhaps name change alone would help correct the mis-perception that "new things can be added only once per year". For some recent history discussion, on how we ended up with "just a number", see mailing list thread on the topic.
- - Largest impact would be to change "MarsSRn" type phrases to simply "Marsn" in the few places it is used.
- - When generic words are needed, instead of numbers, the June Simultaneous Release can be called "the initial yearly Simultaneous Release" and subsequent ones, when generic wording is needed can be called "subsequent release". For example, "Our project typically does XYZ in subsequent releases, not the initial release". [suggestions welcome ... not happy with that exact terminology, but, we should have something to suggest.]
- - This terminology applies primarily to the "Simultaneous Release". Individual projects should still refer to their releases as accurately as possible (service release, or minor release, if not specific number).
- * The "Policy" (currently in Policy FAQ) will be "moved up" to the actual "plan" document. (Just as well move both items into the Plan, even if as footnotes.)
- > In general, "the policy" will emphasize that new projects can join in subsequent, as well as initial releases and projects can contribute "minor releases" as well as "service releases" ... it is up to the project. But, a) must be "backwards compatible" with that train (for example, a minor release that changes "internal methods" into API, should leave the "internal methods" in place, but deprecated) and b) almost never would be a "major release" -- the project would have to be a pure leaf component in Simultaneous Release, and have good reason to believe would not effect any adopters (hard to do, in practice), and would require "exception process" in Planning Council (partially as sanity check, but primarily to ensure well communicated).
- - We need to (also) add milestones for subsequent releases. I propose we have two milestones, M1 [not sure when, yet], and M2 become what we currently call the "warm-up RC". So, we would end up the 2 milestones, and 3 RC's. The milestones are needed primarily for those new projects joining, or those adding large new features. But, as with mainline development, everyone should contribute "their latest", even if just working on service.
- > New Projects or features would have to be in the aggregation build by M2 [Or, should we be stricter, and say M1? -- at least, for Neon's subsequent releases?]
- > [TODO: More of a Neon Item, but consider having more than 2 streams being aggregated. Purpose would be to better enable projects to be working on Release+2 before everyone else is finished with Release+1 (for example).]
Neon Planning
- See initial working draft of plan at Neon/Simultaneous_Release_Plan.
- Continuing Discussion of if and how to change "yearly release"?
- - See "design" wiki page, which acts as centralized place to document the main ideas and plans.
- Was there (and was there any good discussion) at possible meetup during EclipseCon France - see PlanningCouncilToulouse.
New Business
- ?
Next Meeting
- September 5, 2015 - Regular First Wednesday Meeting
Reference
- 2013 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.