Jump to: navigation, search

Planning Council/December 07 2016

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
  • SIP clients:
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)
Fred reported he is working on a Hudson job to automate this, and should be done by end-of-week".
  • 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?
    • We (Platform Project) create a report that runs jdeps during our build. We have to investigate how this can be pushed down to Tyhco.
[dw] FYI, there is a Maven plugin that can be configured. See maven-jdeps-plugin. It does, apparently, offer only "pass/fail" (that is, no setting to list violations as "warnings") so it may not be useful to everyone.
    • I expect to send out information for the projects on January.

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.
-- The issue was that they could not be removed. Appears to be no deep concern.
  • 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.
This item was agreed to put in the "requirements" document. I will work on exact wording and "move up" the 'workspace compatibility' item currently in optional. ACTION-ITEM: Wayne will open a bug for him to update PMI for "release record" with a check box that would have 'unspecified', 'no' 'yes' for a response to "Is Update-able across yearly releases". ACTION-ITEM: dw to open cross-project bug "for issues defining what is means to be 'update-able'".
  • 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.
This item was agreed NOT to put in requirement document. If nothing else it is "too early" since Java 9 is not out yet. But also, there were some concern how important it would be if Java 9 is not truly "backward compatible" then many Eclipse projects may never run well on it. But, the PC thought we, as Eclipse's Leaders, should begin "socializing" the idea of getting ready for it, and what project can/should do, such as Wayne said he may blog about using "jdep" and dw said he may open a cross-project bug about "Java 9 readiness". One thing mentioned was that Eclipse would not run "out of the box" as it currently is, but "out of the box" only the "bare-bones" module would "be in the stack" (at least, as things currently stand).

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.
No comments about importance, so will remove. But will leaving a "closing" comment on the bug, to the effect that "It is hard to make a general rule about it, especially since it is rule that would only apply to projects as part of the Sim. Release. Most of our other rules apply as a "good practice" for any Eclipse project, even if not at the Eclipse Foundation. We agree projects should not install reference repositories when their features are installed but that was more a "project by project" decision and what they judge their users want. Users and adopters are welcome to open bugs against projects that abuse its use, if desired, but nothing the Planning Council could do."

New Business

  •  ?

Next Meeting

  • January 4, 2017 - Regular First Wednesday Meeting

Reference

- Draft Eclipse Project Branding Requirements (Wayne)
- Neon Wiki page
- Oxygen Wiki page
- Planning Council Members
- Simultaneous Release Roles and Simultaneous Release Roles/EMO