December_07_2016.md
October 9, 2023 ยท View on GitHub
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
width="100%" valign="top" |
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
width="100%" valign="top" |
|
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. ()
-
*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](https://maven.apache.org/plugins/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 .
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 .
\- 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 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]:
Again, projects can simply say "no", but then at least we (and users) would know.\- 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.
-
*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
- For details, see .
- 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