Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Planning Council/November 02 2016"
(/* Neon maintenance Lots of action items!) |
(→Oxygen Planning: license check style identification for projects in the SimRel update site, eg., Thym, JSDT) |
||
| Line 172: | Line 172: | ||
== Oxygen Planning == | == Oxygen Planning == | ||
| + | === Java 9 Coordination === | ||
* Java 9 Coordination [Dani]. After discussing what to do about Java 9 date changing, at a previous meeting, we also discussed the need for "Java 9 coordination". Dani, is this a fair summary of that work item: | * Java 9 Coordination [Dani]. After discussing what to do about Java 9 date changing, at a previous meeting, we also discussed the need for "Java 9 coordination". Dani, is this a fair summary of that work item: | ||
:: 1) Find out which other projects plan to participate in a likely "July Java 9 update" (that is who is plans to "support Java 9 during development time"?) | :: 1) Find out which other projects plan to participate in a likely "July Java 9 update" (that is who is plans to "support Java 9 during development time"?) | ||
:: 2) Educate projects on how and WHEN to test their code ''''running'''' on Java 9. Ideally, as projects test on Java 9 there will be a synergy where projects will educate each other on what was discovered and what others should look for (perhaps on a wiki, somewhere). | :: 2) Educate projects on how and WHEN to test their code ''''running'''' on Java 9. Ideally, as projects test on Java 9 there will be a synergy where projects will educate each other on what was discovered and what others should look for (perhaps on a wiki, somewhere). | ||
| + | === Release Train Number vs. Name === | ||
* There has been a lot of discussion about "giving up release name" and using "date" instead. See {{bug|493490}}. | * There has been a lot of discussion about "giving up release name" and using "date" instead. See {{bug|493490}}. | ||
| Line 184: | Line 186: | ||
::Summary of our position: decided that we can not "solve" this issue for Oxygen, but we can make incremental improvement. After that incremental improvement, we may have a better idea of the core problem to fix. As things are now, there is little chance of getting agreement on what the problem is or how to fix it. As of now, it is sort of like saying that "the problem is that things are confusing" -- too broad to fix all at once. We do not want to abandon the "code name" (at least for now) based on what we know. It is highly recommend that specific areas where confusion is seen that bugs be opened with a suggestion on how to improve. This includes web pages, splash screens, tutorials, instructions, announcements, press releases, and anything else where "version" and "code name" and "contents of deliverable" are confused. In general it is recommended that any place the code name is used there needs to be more information: such as version or date or build id (depending on context). Also, I think that "check for update" should give some indication that a "whole new stream" is available -- as the Installer currently does. | ::Summary of our position: decided that we can not "solve" this issue for Oxygen, but we can make incremental improvement. After that incremental improvement, we may have a better idea of the core problem to fix. As things are now, there is little chance of getting agreement on what the problem is or how to fix it. As of now, it is sort of like saying that "the problem is that things are confusing" -- too broad to fix all at once. We do not want to abandon the "code name" (at least for now) based on what we know. It is highly recommend that specific areas where confusion is seen that bugs be opened with a suggestion on how to improve. This includes web pages, splash screens, tutorials, instructions, announcements, press releases, and anything else where "version" and "code name" and "contents of deliverable" are confused. In general it is recommended that any place the code name is used there needs to be more information: such as version or date or build id (depending on context). Also, I think that "check for update" should give some indication that a "whole new stream" is available -- as the Installer currently does. | ||
| + | === License Check Styles === | ||
* New levels of IP. | * 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? | :- 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? | ||
| Line 191: | Line 194: | ||
::- Some projects that want to use this new Type A policy, such as Orion, have always been "part of the Simultaneous Release", but not part of the Sim. Release repository. It is only the repository that we are saying it is required for, not the Release, per se. | ::- Some projects that want to use this new Type A policy, such as Orion, have always been "part of the Simultaneous Release", but not part of the Sim. Release repository. It is only the repository that we are saying it is required for, not the Release, per se. | ||
::- "How labeled" may make a difference. For example, as far as we know, it is still required that any EPP package that contain "incubating projects" label the whole EPP package as "incubating". Could there be something similar for "Type A" or "Type B" projects? And, the methods must be meaningfully named to be usable (by users); not just "Type A" and "Type B". | ::- "How labeled" may make a difference. For example, as far as we know, it is still required that any EPP package that contain "incubating projects" label the whole EPP package as "incubating". Could there be something similar for "Type A" or "Type B" projects? And, the methods must be meaningfully named to be usable (by users); not just "Type A" and "Type B". | ||
| − | :* '''New for Nov 2 meeting:''' Nick Boldt has some new information and questions and a proposal that he posted to [https://dev.eclipse.org/mhonarc/lists/eclipse.org-planning-council/msg02666.html PC mailing list message]. | + | ==== License check style identification for projects in the SimRel update site, eg., Thym, JSDT ==== |
| + | :* '''New for Nov 2 meeting:''' Nick Boldt has some new information and questions and a proposal that he posted to [https://dev.eclipse.org/mhonarc/lists/eclipse.org-planning-council/msg02666.html PC mailing list message]. Discussion outcome: | ||
| + | ::* release records will be updated to include which level of due diligence (Type A or B). | ||
| + | ::* Type A / Type B applies to third party libraries ONLY, not to the project's code itself. | ||
| + | ::* Wayne explicitly does NOT want Type A to be considered bad, stigmatized, or in any way like Incubating | ||
| + | ::* if a hypothetical company wants to invest resources to move a project from Type A back to B, they could do so; they could also do the additional provenance checking and never report back to the Foundation or the project. | ||
| + | ::* '''To be resolved:''' where should license check style be placed in release records? As a new section on [https://projects.eclipse.org/projects/tools.thym/releases/2.0.0 release record] or a new blurb in the [https://projects.eclipse.org/projects/tools.thym/reviews/2.0.0-release-review release doc] itself? | ||
| + | ::* '''To be resolved:''' should projects use [https://github.com/eclipse/thym/blob/master/plugins/org.eclipse.thym.core/about.html plugins' about.html], [https://github.com/eclipse/thym/blob/master/features/org.eclipse.thym.feature/license.html features' license.html], or a [https://github.com/eclipse/thym/blob/master/LICENSE LICENSE file] to identify the license check style? | ||
| + | |||
| + | === Annual Updates Across Releases === | ||
* Should the ability to update from yearly release to yearly release be a 'requirement'? | * Should the ability to update from yearly release to yearly release be a 'requirement'? | ||
| Line 209: | Line 221: | ||
::: Eventually I assume we would want a built-in stream-less URL. I am assuming for Oxygen we want have a stream-less URL available, but not built in, to enable testing the update from Neon to Oxygen. (See {{bug|483786}}) | ::: Eventually I assume we would want a built-in stream-less URL. I am assuming for Oxygen we want have a stream-less URL available, but not built in, to enable testing the update from Neon to Oxygen. (See {{bug|483786}}) | ||
| + | ===Release Policy vs. Release Mechanics=== | ||
* Release Policy vs. Release mechanics. This is being tracked in {{bug|483322}}. | * Release Policy vs. Release mechanics. This is being tracked in {{bug|483322}}. | ||
Revision as of 13:50, 2 November 2016
Contents
Logistics
| Meeting Title: | Planning Council Conference Call |
| Date & Time: | Wednesday, Nov 02, 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
- Are we done with these Neon.1 issues?
- Was "Neon.1 help" ever deployed? See bug 500938.
- - ACTION_ITEM: David to discuss with Fred to determine state and make sure "what we know" is deployed.
- - Then focus needs to be on bug 499411 to make things easier for all future releases.
- [Wayne?] Create New and Noteworthy for Neon.1 (bug 500939)
- - I assume we can "declare victory" but are "we" (Wayne?) prepared to do this for all future update releases (and primary releases)? Do we "need a documented process"?
- - ACTION_ITEM: Wayne to "close out" the current bug and document there (or, link to a wiki page) on what the process is moving forward. I bet it will involve PMI. :)
- Any issues for Neon.2? Any new projects joining? I assume some will have new features? (But I do not know what they are. Does anyone?)
- - no issues known for Neon.2
- - ACTION_ITEM: Wayne to tweak PMI so that projects can document their new features for update releases. The "documentation" is primarily to improve communication to the community on "why they should care" about a particular release but there could be other consumers such as translators or tutorial writers may need react. (This is required, since "update releases" are no longer "maintenance releases".)
Oxygen Planning
Java 9 Coordination
- Java 9 Coordination [Dani]. After discussing what to do about Java 9 date changing, at a previous meeting, we also discussed the need for "Java 9 coordination". Dani, is this a fair summary of that work item:
- 1) Find out which other projects plan to participate in a likely "July Java 9 update" (that is who is plans to "support Java 9 during development time"?)
- 2) Educate projects on how and WHEN to test their code 'running' on Java 9. Ideally, as projects test on Java 9 there will be a synergy where projects will educate each other on what was discovered and what others should look for (perhaps on a wiki, somewhere).
Release Train Number vs. Name
- There has been a lot of discussion about "giving up release name" and using "date" instead. See bug 493490.
- - Further discussion in a previous meeting lead to the idea that one thing that is missing is what DO we call the thing we are releasing. "Eclipse Neon" seems too vague and definitely sounds like a different thing than "Eclipse Mars" (even if you add "release". Some quick suggestions were "Eclipse IDE - Neon Version" or similar (with dates, probably).
- - What's wrong with "Package"?
- - Main ACTION ITEM is that we owe the community some official response on bug 493490 about what our official PC plan or response is. Is there agreement the following is our official position? If so, I will comment in bug 493490.
- Summary of our position: decided that we can not "solve" this issue for Oxygen, but we can make incremental improvement. After that incremental improvement, we may have a better idea of the core problem to fix. As things are now, there is little chance of getting agreement on what the problem is or how to fix it. As of now, it is sort of like saying that "the problem is that things are confusing" -- too broad to fix all at once. We do not want to abandon the "code name" (at least for now) based on what we know. It is highly recommend that specific areas where confusion is seen that bugs be opened with a suggestion on how to improve. This includes web pages, splash screens, tutorials, instructions, announcements, press releases, and anything else where "version" and "code name" and "contents of deliverable" are confused. In general it is recommended that any place the code name is used there needs to be more information: such as version or date or build id (depending on context). Also, I think that "check for update" should give some indication that a "whole new stream" is available -- as the Installer currently does.
License Check Styles
- 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?
- - Wayne has opened bug bug 501014 for comments.
- From previous meeting, we decided our initial position should be "status quo" -- that is, to say it is required that each project in the Sim. release repository (and EPP packages) be of Type B. A few reasons given:
- - Adopters or users may be surprised to get a different legal process than what they are used to. This not only concerns adopters which build stand alone commercial product, but some build features which prereq certain EPP packages are installed, so they direct their customers to install those packages first, and then install their features. Plus, while is it commonly believed "users don't care", many of those users work for corporations or government agencies which do care. For example, the corporation may have a policy that "it is ok to download and install things from Eclipse where all the code has been "reviewed as Type B". But those corporations might also they their developers: "it is not ok to download open source in general and not even from Eclipse for Type A". It is unlikely to get corporations to state what their internal policies are, since they would consider that confidential, so it just seems safest to go with "status quo" -- until we learn otherwise or have good reason to change.
- - Some projects that want to use this new Type A policy, such as Orion, have always been "part of the Simultaneous Release", but not part of the Sim. Release repository. It is only the repository that we are saying it is required for, not the Release, per se.
- - "How labeled" may make a difference. For example, as far as we know, it is still required that any EPP package that contain "incubating projects" label the whole EPP package as "incubating". Could there be something similar for "Type A" or "Type B" projects? And, the methods must be meaningfully named to be usable (by users); not just "Type A" and "Type B".
License check style identification for projects in the SimRel update site, eg., Thym, JSDT
- New for Nov 2 meeting: Nick Boldt has some new information and questions and a proposal that he posted to PC mailing list message. Discussion outcome:
- release records will be updated to include which level of due diligence (Type A or B).
- Type A / Type B applies to third party libraries ONLY, not to the project's code itself.
- Wayne explicitly does NOT want Type A to be considered bad, stigmatized, or in any way like Incubating
- if a hypothetical company wants to invest resources to move a project from Type A back to B, they could do so; they could also do the additional provenance checking and never report back to the Foundation or the project.
- To be resolved: where should license check style be placed in release records? As a new section on release record or a new blurb in the release doc itself?
- To be resolved: should projects use plugins' about.html, features' license.html, or a LICENSE file to identify the license check style?
Annual Updates Across Releases
- Should the ability to update from yearly release to yearly release be a 'requirement'?
- ACTION ITEM from 6/8 meeting. Doug volunteered to "take up" this item to better specify "what does it mean" and "what will it take" to update across major releases. After last meeting, Doug, mentioned he thinks this is a UI issue and he would take it up with the UI task force. I do not think it is only a UI issue, but from our point of view, more a matter of what we expect projects to do differently. As I have listed before:
- What would this take? Such as,
- features can never be removed but can be replaced with some form of transition. See bug 314165 and bug 371302.
- Preferences, views, etc. have to "migrate" (if their ID changes)?
- What testing would projects have to do?
- What is the effect on commercial products? That is, will their customers get sufficient information that they "... can not upgrade without voiding their warranty", so to speak?
- Have we ever had a case where year-to-year updates worked? (For everything.)
- For Neon, it was the change in package layouts. (Hence we backed-off having a "streamless URL".)
- For Luna? it was the change in MacOS layouts
- For Mars? it was the Window executable could not be updated. (Now it can be, as long as it is named exactly 'eclipse.exe').
- Eventually I assume we would want a built-in stream-less URL. I am assuming for Oxygen we want have a stream-less URL available, but not built in, to enable testing the update from Neon to Oxygen. (See bug 483786)
- What would this take? Such as,
Release Policy vs. Release Mechanics
- Release Policy vs. Release mechanics. This is being tracked in 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)?
New Business
- ?
Next Meeting
- November 7, 2016 - Regular First Wednesday Meeting
Reference
- Draft Eclipse Project Branding Requirements (Wayne)