| Meeting Title:
|| Planning Council Conference Call
| Date & Time:
|| Wednesday, June 3, 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
- call firstname.lastname@example.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)
| Steffen Pingel (Sam Davis)
|| Mylyn (ALM) PMC
| Brian Payton
|| Datatools (PMC)
| Doug Schaefer
|| Tools (PMC)
| Adrian Mos (Marc Dutoo )
|| SOA (PMC)
| Ed Merks
|| Modeling (PMC)
| Ian Bull
|| Rt (PMC)
| Chuck Bridgham
|| WTP (PMC)
| Wayne Beaton
|| Eclipse Foundation (appointed)
| David Williams
|| (appointed Chair)
| Max Andersen? (and Nick Boldt)
|| Redhat (Strategic Developer)
| Remi Schnekenburger
|| CEA List (Strategic Developer)
| Cedric Brun
|| OBEO (Strategic Developer)
| Neil Hauge
|| Oracle (Strategic Developer)
| Stephan Merker
|| SAP AG (Strategic Developer)
| Markus Knauer
|| Innoopract (Strategic Developer)
| Rajeev Dayal
|| Google (Strategic Developer)
| (PMC rep)
|| Actuate (Strategic Developer)
| (PMC rep)
|| IBM (Strategic Developer)
| [no name]
|| CA Inc. (Strategic Consumer)
| [no name]
|| Birt (PMC)
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
Previous meeting minutes
- What happened to "WindowBuilder"?
Progress on Action Items
- Improving user experience in finding right function to install. For latest ideas, see
- bug 459905 - Create a Marketplace for the simultaneous release.
- "The action that [Wayne thinks] we should take is to shut down the Eclipse Project market and close this bug as WONTFIX."
- Continuing Discussion of if and how to change "yearly release"?
- I have started a "design" wiki page, to act as a "design document", to help centralize the main points we have discussed.
- Notes from the last meeting:
- Seemed to be rough agreement that to "release more frequently" would be good ... for projects and perception.
- Was discussion that "6 per year" too many ... "2 per year" not enough. So settled on "4 per year" as a working assumption.
- Did not really discuss WHEN they would be (which months), but (I think) general agreement they should be regular, and predictable.
- Did not really discuss what to call them. We want to convey they are true releases, but, releases with no subsequent service release.
- "SR" name especially bad for perception, since it is not really just "service releases" any more.
- But, even if we had 4 releases per year, some might put in "just service", some might put in new features, so adds some complexity on what and how to communicate (with each other, and community).
- We would always (still) need "two streams" going ... one for "next immediate release", ... another stream for "long term work". (Or, may vary by project?)
- We did NOT discuss how to manage that ... would "long term work" be merged into "release" stream at certain points?
- We would (still) want something like a yearly "LTS Release".
- We did say it would take at least 2 months for us to have a concrete proposal.
- Need to emphasize (at least to ourselves) that one of goals is to change perceptions.
- Current perception is that Eclipse is slow moving, with "new things" only coming out yearly. While this is not technically true, it is the perception.
- Point made that to call them "one major release" and "3 minor releases" would be more accurate than "4 releases".
- We would expect at most "minor field" only updates (not major, API breaking, field changes).
- But new features can still be added.
- And new projects can still join. (Need to codify what's required, especially in terms of "join early").
- The minor releases should all be upgradeable from previous.
- Implies some constraints even on "non API" methods continuing to work, if used by others as if API.
- General agreement that "UI can change" (but, hard to know at the moment, if there are some limits ... such as impacts to translations, etc.)
- We may want to codify different rules for the different "categories" of 0, +1, +2, +3.
- Some doubted we could codify that, but could at least mention "good will" and "cooperation" between the different levels
- Some wanted new requirement to be upgradeable year to year, as well as from minor to minor.
- Hard to know, at present, if that is possible, or what new work it would involve?
- But we should at least understand what it would take, and if there are inhibitors to doing that, see if they can be addressed.
- The point was made that some projects, even now, have their own milestone schedule and builds, but skip putting things in Sim. Release train "until the end" which then causes surprise.
- Was wondered if we could improve our automation to 'detect' when no changes have been made, in Sim. Release, so then at least there would be a record of it -- something to open bugs about, or to codify that projects "must" contribute, if they have changes.
- (This didn't come up, in the abstract, but there was a known case, I believe Sapphire was mentioned.)
- * ?
- August 5, 2015 - Regular First Wednesday Meeting -- We traditionally skip July, since a) just released b) Holidays and vacations.
- 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