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.)
- 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 710@asterisk.eclipse.org, then enter pin 35498.
|
Members and Attendees
PMC (and Strategic) Reps
Martin Lippert
|
Cloud (PMC)
|
Y
|
Chris Aniszczyk
|
Technology (PMC)
|
|
Dani Megert
|
Eclipse (PMC)
|
Y
|
Sam Davis
|
Mylyn (ALM) PMC
|
Y
|
Doug Schaefer
|
Tools (PMC)
|
Y
|
Ian Bull
|
Rt (PMC)
|
|
Adrian Mos
|
SOA (PMC)
|
D (Bob Brodt)
|
Fred Gurr
|
Eclipse Foundation (releng)
|
Y
|
Wayne Beaton
|
Eclipse Foundation (appointed)
|
Y
|
David Williams
|
(appointed Chair)
|
Y
|
|
Strategic Reps
Marc Khouzam
|
Ericsson
|
|
Alexander Nyssen
|
itemis AG (Strategic Developer)
|
Y
|
Nick Boldt
|
Red Hat (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
|
EPP (appointed)
|
|
(has PMC rep; Dani Megert)
|
IBM (Strategic Developer)
|
X
|
|
Inactive
[no name]
|
CA Inc. (Strategic Consumer)
|
X
|
(was Gary Xue)
|
Birt (PMC)
|
X
|
(has/had PMC rep)
|
Actuate (Strategic Developer)
|
X
|
(was Rajeev Dayal)
|
Google (Strategic Developer)
|
X
|
Ed Merks
|
Modeling (PMC)
|
X
|
Brian Payton
|
Datatools (PMC)
|
X
|
Chuck Bridgham
|
WTP (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 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?
It appears the names "Type A" and "Type B" will stay. Wayne had some ideas on how to describe them on any user facing pages, such as "License Compatibility" for former and "License Compatibility, providence, and code scans" for the latter. And, it appears the only way to tell will be to look in the IP Log (and maybe Release Docs?). No one at the meeting voiced any issue with that.
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
- 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?]
Reference
- - Draft Eclipse Project Branding Requirements (Wayne)
- - Neon Wiki page
- - Oxygen Wiki page
- - Planning Council Members
- - Simultaneous Release Roles and Simultaneous Release Roles/EMO