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/June 03 2015"
m (/* Progress on Action Items) |
(/* Progress on Action Items) |
||
| (7 intermediate revisions by 3 users not shown) | |||
| Line 34: | Line 34: | ||
|+ '''PMC (and Strategic) Reps''' | |+ '''PMC (and Strategic) Reps''' | ||
|- | |- | ||
| − | | John Arthorne ( | + | | John Arthorne (occasional) |
| Cloud (PMC) | | Cloud (PMC) | ||
| − | | | + | | R |
|- | |- | ||
| Chris Aniszczyk | | Chris Aniszczyk | ||
| Line 44: | Line 44: | ||
| Dani Megert | | Dani Megert | ||
| Eclipse (PMC) | | Eclipse (PMC) | ||
| − | | | + | | Y |
|- | |- | ||
| Steffen Pingel (Sam Davis) | | Steffen Pingel (Sam Davis) | ||
| Line 56: | Line 56: | ||
| Doug Schaefer | | Doug Schaefer | ||
| Tools (PMC) | | Tools (PMC) | ||
| − | | | + | | Y |
|- | |- | ||
| Adrian Mos (Marc Dutoo ) | | Adrian Mos (Marc Dutoo ) | ||
| Line 68: | Line 68: | ||
| Ian Bull | | Ian Bull | ||
| Rt (PMC) | | Rt (PMC) | ||
| − | | | + | | Y |
|- | |- | ||
| Chuck Bridgham | | Chuck Bridgham | ||
| WTP (PMC) | | WTP (PMC) | ||
| − | | | + | | Y |
|- | |- | ||
| Wayne Beaton | | Wayne Beaton | ||
| Line 86: | Line 86: | ||
|+ '''Strategic Reps''' | |+ '''Strategic Reps''' | ||
|- | |- | ||
| − | | Max Andersen? | + | | Max Andersen? (and Nick Boldt) |
| Redhat (Strategic Developer) | | Redhat (Strategic Developer) | ||
| − | | | + | | Y |
|- | |- | ||
| Remi Schnekenburger | | Remi Schnekenburger | ||
| CEA List (Strategic Developer) | | CEA List (Strategic Developer) | ||
| − | | | + | | Y |
|- | |- | ||
| Cedric Brun | | Cedric Brun | ||
| Line 104: | Line 104: | ||
| Stephan Merker | | Stephan Merker | ||
| SAP AG (Strategic Developer) | | SAP AG (Strategic Developer) | ||
| − | | | + | | R |
|- | |- | ||
| Markus Knauer | | Markus Knauer | ||
| Innoopract (Strategic Developer) | | Innoopract (Strategic Developer) | ||
| − | | | + | | Y |
|- | |- | ||
| Rajeev Dayal | | Rajeev Dayal | ||
| Line 152: | Line 152: | ||
* Any issues? | * Any issues? | ||
| + | :* What happened to "WindowBuilder"? | ||
== Progress on Action Items == | == Progress on Action Items == | ||
| Line 157: | Line 158: | ||
* Improving user experience in finding right function to install. For latest ideas, see | * Improving user experience in finding right function to install. For latest ideas, see | ||
: {{bug|459905}} - Create a Marketplace for the simultaneous release. | : {{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"? | * Continuing Discussion of if and how to change "yearly release"? | ||
:* I have started a [[SimRel/ChangingProcessAndTiming| "design" wiki page]], to act as a "design document", to help centralize the main points we have discussed. | :* I have started a [[SimRel/ChangingProcessAndTiming| "design" wiki page]], to act as a "design document", to help centralize the main points we have discussed. | ||
| + | |||
:* Notes from the last meeting: | :* Notes from the last meeting: | ||
| − | + | <hr/> | |
* Seemed to be rough agreement that to "release more frequently" would be good ... for projects and perception. | * 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. | * Was discussion that "6 per year" too many ... "2 per year" not enough. So settled on "4 per year" as a working assumption. | ||
| Line 174: | Line 177: | ||
* We would (still) want something like a yearly "LTS Release". | * 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. | * We did say it would take at least 2 months for us to have a concrete proposal. | ||
| − | : | + | <hr/> |
| + | :* Notes from this meeting | ||
| + | <hr/> | ||
| + | :* 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.) | ||
| + | |||
| + | <hr/> | ||
== New Business == | == New Business == | ||
| − | : * | + | : * ? |
== Next Meeting == | == 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. | * August 5, 2015 - Regular First Wednesday Meeting -- We traditionally skip July, since a) just released b) Holidays and vacations. | ||
Latest revision as of 13:21, 3 June 2015
Contents
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
|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
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
- 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.
- 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 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.