Skip to main content
Jump to: navigation, search

Planning Council/December 07 2016

< Planning Council
Revision as of 13:24, 7 December 2016 by David williams.acm.org (Talk | contribs) (/* Members and Attendees)

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)
  • 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

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

Back to the top