June_03_2015.md
October 9, 2023 ยท View on GitHub
Logistics
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.)
|
Members and Attendees
width="100%" valign="top" |
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
width="100%" valign="top" |
|
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
- Welcome ...
Previous meeting minutes
- Review previous meeting minutes if you'd like.
Mars Planning
- Any issues?
:* What happened to "WindowBuilder"?
Progress on Action Items
- Improving user experience in finding right function to install. For latest ideas, see
\- 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.
:* Notes from this meeting
:* 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.)
New Business
- * ?
Next Meeting
- Possible meetup during EclipseCon France - see PlanningCouncilToulouse.
- August 5, 2015 - Regular First Wednesday Meeting -- We traditionally skip July, since a) just released b) Holidays and vacations.
Reference
- 2013 EclipseCon face-to-face follow-through action items. For original meeting notes, see March_24_2013 and for discussion leading to action items, see April_10_2013. For last status update, see May_8_2013.