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.
Difference between revisions of "Planning Council/December 07 2016"
m (/* Next Meeting - fixed date) |
m (/* Members and Attendees) |
||
Line 36: | Line 36: | ||
| Martin Lippert | | Martin Lippert | ||
| Cloud (PMC) | | Cloud (PMC) | ||
− | | | + | | Y |
|- | |- | ||
| Chris Aniszczyk | | Chris Aniszczyk | ||
Line 44: | Line 44: | ||
| Dani Megert | | Dani Megert | ||
| Eclipse (PMC) | | Eclipse (PMC) | ||
− | | | + | | Y |
|- | |- | ||
| Sam Davis | | Sam Davis | ||
| Mylyn (ALM) PMC | | Mylyn (ALM) PMC | ||
− | | | + | | Y |
|- | |- | ||
| Doug Schaefer | | Doug Schaefer | ||
| Tools (PMC) | | Tools (PMC) | ||
− | | | + | | Y |
|- | |- | ||
| Ian Bull | | Ian Bull | ||
| Rt (PMC) | | Rt (PMC) | ||
| | | | ||
+ | |- | ||
+ | | Adrian Mos | ||
+ | | SOA (PMC) | ||
+ | | D (Bob Brodt) | ||
+ | |- | ||
+ | | Fred Gurr | ||
+ | | Eclipse Foundation (releng) | ||
+ | | Y | ||
|- | |- | ||
| Wayne Beaton | | Wayne Beaton | ||
| Eclipse Foundation (appointed) | | Eclipse Foundation (appointed) | ||
− | | | + | | Y |
|- | |- | ||
| David Williams | | David Williams | ||
| (appointed Chair) | | (appointed Chair) | ||
− | | | + | | Y |
|} | |} | ||
| | | | ||
Line 76: | Line 84: | ||
| Alexander Nyssen | | Alexander Nyssen | ||
| itemis AG (Strategic Developer) | | itemis AG (Strategic Developer) | ||
− | | | + | | Y |
|- | |- | ||
| Nick Boldt | | Nick Boldt | ||
Line 130: | Line 138: | ||
| Modeling (PMC) | | Modeling (PMC) | ||
| X | | X | ||
− | |||
− | |||
− | |||
− | |||
|- | |- | ||
| Brian Payton | | Brian Payton |
Revision as of 14:24, 7 December 2016
Contents
Logistics
Meeting Title: | Planning Council Conference Call |
Date & Time: | Wednesday, Dec 07, 2016, 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 the meeting, but if questions or issues with previous minutes, this would be a good time to bring them up.
Neon maintenance
- Remaining from previous action item: Need to establish new "Info Center procedure" for Neon.2. (bug 499411)
- FYI from previous "New and Noteworthy" action item:
- - Wayne added New and Noteworthy procedure to
- https://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements/Appendix#New_and_Noteworthy
- - and I added short pointer to it in the "Final Daze" document
- https://wiki.eclipse.org/Neon/Final_Daze#Provide_input_for_overall_New_and_Noteworthy
Oxygen Planning
Java 9 Coordination [Dani]
- Dani, anything to report?
Stop using Release Name?
- Reminder to open bugs where "release name" is used by itself: See bug 493490.
New levels of IP
- - Do we, as Planning Council, want to stipulate a participating project must be of "type B"? Or, do we not care? It may depend on "how labeled"? How do users or companies know? What do they expect? Comment in bug 501014.
- - In a previous meeting are most recent conclusion was:
- - "Anyone can be in the Simultaneous Release repository regardless of IP method chosen". :::- But, this was conditional on users and adopters being able to easily know which method applies -- in case it does matter to them. Suggestions were made to provide meaningful names (other than "Type A and Type B") and to provide the information in something like the about.html file. We all agreed with Wayne that it should not be part of a package name or bundle id, etc. Just something more "self documenting" than the "release record" (Wayne's currently planning on providing that).
- - Wayne, any news on "names" or how "documented" for end-users and adopters?
Potential new requirements
- Should the ability to update from yearly release to yearly release be a 'requirement'?
- From last meeting:
- - After a brief discussion, it was decided this should not be a requirement though we should encourage projects to test that scenario and keep track of issues.
- - Doug surprised us all saying current "root features" do not work as expected. That items can to be removed or added? Doug, please clarify in bug 505378 what issues you are seeing.
- I would like to suggest we "beef up" our current "update" policy:
- - It is currently captured as an "optional" requirement. See
- https://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements/Appendix#Compatibility_with_Previous_Releases
- I propose moving it to "required", where the required part is to simply document if the project supports updating from previous yearly releases. And we should be explicit that "supports updating ..." means:
- - Testing it
- - Accepting bugs against it
- - Following best practices, such as migrating preferences that changed ids, etc. [Can anyone provide more detail here?]
- Naturally, a project may decide to document "No, not supported", but then at least we (and users) would know.
- Similarly, I propose we require that projects document if they are "Java 9 ready".
- - This would mean [more detail welcome]:
- - They have tested running on Java 9.
- - Will accept bugs that occur only when running on on Java 9.
- - They have tested with "jdepends" for "VM internal use" methods. (And, ideally, removed such uses).
- - Anything else?
- - If a project provides Java "functionality" (such as generating code, having special natures, etc.) that they either have that functionality in Oxygen, or will have for the "Java 9 update release" currently planned for July.
- Again, projects can simply say "no", but then at least we (and users) would know.
Release Policy vs. Release mechanics
- For details, see bug 483322.
- In Neon M6 we changed to have (nearly) all features to be "root features.
- Now what? That is, can we "stop" adding "reference repositories" via feature p2.inf files?
- Can we make an official policy on "off scheduled fixes" (as we are considering for MPC)?
- - We have not discussed this topic for a long time. I think it is important, but will remove from "ongoing issues" unless someone at December meeting asks that it remain.
New Business
- ?
Next Meeting
- January 4, 2017 - Regular First Wednesday Meeting [Any discussion? Is everyone "back to work" that first week? Or, should we postpone until January 11?]