Skip to main content

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.

Jump to: navigation, search

Planning Council/August 05 2015

< Planning Council
Revision as of 13:45, 6 August 2015 by David williams.acm.org (Talk | contribs) (Members and Attendees)

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

For all phone lines: Participant conference extension: 710 then enter pin 35498
  • Ottawa (local call in Ottawa) 1-613-454-1403
  • North America (toll free) 1-866-569-4992
  • Germany (local call anywhere in Germany) +49-692-2224-6059
  • France (local call anywhere in France) +33-17-070-8535
  • UK (toll free) 0800-033-7806
  • Switzerland (local call anywhere in Switzerland) +41-44-580-2115
  • SIP clients:
call 710@asterisk.eclipse.org, then enter pin 35498.

Members and Attendees

PMC (and Strategic) Reps
John Arthorne (occasional) Cloud (PMC)
Chris Aniszczyk Technology (PMC)
Dani Megert Eclipse (PMC) Y
Steffen Pingel (Sam Davis) Mylyn (ALM) PMC D (?Chan?)
Brian Payton Datatools (PMC)
Doug Schaefer Tools (PMC) Y
Adrian Mos (Marc Dutoo ) SOA (PMC)
Ed Merks Modeling (PMC)
Ian Bull Rt (PMC) R
Chuck Bridgham WTP (PMC)
Wayne Beaton Eclipse Foundation (appointed) Y
David Williams (appointed Chair) Y
Strategic Reps
Nick Boldt Redhat (Strategic Developer) Y
Remi Schnekenburger CEA List (Strategic Developer)
Cedric Brun OBEO (Strategic Developer)
Neil Hauge Oracle (Strategic Developer)
Stephan Merker SAP AG (Strategic Developer) Y
Markus Knauer Innoopract (Strategic Developer)
Rajeev Dayal Google (Strategic Developer)
(PMC rep) Actuate (Strategic Developer) X
(PMC rep) IBM (Strategic Developer) X
Inactive
[no name] CA Inc. (Strategic Consumer) X
[no name] Birt (PMC) X

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 proposing a "point number", see mailing list thread on the topic.
- Largest impact would be to change "MarsSRn" type phrases to simply "Mars.n" 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 "update (number)" or "point number" or "dot number". For example, "Our project typically does XYZ in update 1, not the initial release".
- 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 update 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 Update+2 before everyone else is finished with Update+1 (for example).]

Neon Planning

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.
Mars Wiki page
Planning Council Members
Simultaneous Release Roles and Simultaneous Release Roles/EMO

Back to the top