Skip to main content

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.

Jump to: navigation, search

Difference between revisions of "Planning Council/October 05 2016"

m (New Business)
m (/* Neon maintenance)
Line 159: Line 159:
 
== Neon maintenance ==  
 
== Neon maintenance ==  
  
* Do we need a "rebuild" for {{bug|501000}}?
+
* Do we need a "rebuild" for {{bug|501000}}? Will also include {{bug|498553}}. See also {{bug|502937}} where I would like to try a "new" method of creating "off-schedule" fixes to Sim. Release Repo.
 
: See also the [https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg13693.html message to cross-project list].  
 
: See also the [https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg13693.html message to cross-project list].  
: - BUT, there has been no official request via Technology PMC or their Planning rep.  
+
: <del>- BUT, there has been no official request via Technology PMC or their Planning rep.</del>
 +
: A [https://dev.eclipse.org/mhonarc/lists/eclipse.org-planning-council/msg02650.html formal request] has been made -- with [https://dev.eclipse.org/mhonarc/lists/eclipse.org-planning-council/msg02651.html one vote] so far -- can someone give a second? Any objections?
 +
 
  
 
* Are we done with these?  
 
* Are we done with these?  
 
:- Will soon need a Neon.1 info center ({{bug|500938}})
 
:- Will soon need a Neon.1 info center ({{bug|500938}})
:: Such as, Eclipse platform did change some docs, but they did not respond or list them in {{bug|500938}}.
+
:: Such as, Eclipse platform did change some docs, but they did not respond or list them in {{bug|500938}}. (See {{bug|499411#c11}} for list of Platform doc changes.)
 
:: A related topic: anyone see an issue with implementing an automatic process to find bundles with "toc" extension in plugin.xml and using that as our "help input"? See {{bug|499411}}
 
:: A related topic: anyone see an issue with implementing an automatic process to find bundles with "toc" extension in plugin.xml and using that as our "help input"? See {{bug|499411}}
 
:- [Wayne?] Create New and Noteworthy for Neon.1 ({{Bug|500939}})
 
:- [Wayne?] Create New and Noteworthy for Neon.1 ({{Bug|500939}})

Revision as of 11:53, 5 October 2016

Logistics

Meeting Title: Planning Council Conference Call
Date & Time: Wednesday, June 8, 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)
Chris Aniszczyk Technology (PMC)
Dani Megert Eclipse (PMC)
Sam Davis Mylyn (ALM) PMC
Brian Payton Datatools (PMC)
Doug Schaefer Tools (PMC)
Ian Bull Rt (PMC)
Chuck Bridgham WTP (PMC)
Wayne Beaton Eclipse Foundation (appointed)
David Williams (appointed Chair)
Strategic Reps
Marc Khouzam Ericsson
Alexander Nyssen itemis AG (Strategic Developer)
Nick Boldt Redhat (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
Adrian Mos (Marc Dutoo ) SOA (PMC) X-R(2)

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

  • Do we need a "rebuild" for bug 501000? Will also include bug 498553. See also bug 502937 where I would like to try a "new" method of creating "off-schedule" fixes to Sim. Release Repo.
See also the message to cross-project list.
- BUT, there has been no official request via Technology PMC or their Planning rep.
A formal request has been made -- with one vote so far -- can someone give a second? Any objections?


  • Are we done with these?
- Will soon need a Neon.1 info center (bug 500938)
Such as, Eclipse platform did change some docs, but they did not respond or list them in bug 500938. (See bug 499411#c11 for list of Platform doc changes.)
A related topic: anyone see an issue with implementing an automatic process to find bundles with "toc" extension in plugin.xml and using that as our "help input"? See bug 499411
- [Wayne?] Create New and Noteworthy for Neon.1 (bug 500939)

Oxygen Planning

  • There has been a lot of discussion about "giving up release name" and using "date" instead. See bug 493490.
- Further discussion in the 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).
  • - ACTION ITEM: Doug said he would try to re-ignite the discussion via blog or similar.
  • - Main point is that we owe the community some response on bug 493490 about what our plan will be.

During [previous] meeting, it was decided that we can not "solve" for Oxygen, but we can probably 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. It is sort of like now the problem is "things are confusing" -- a little too broad to fix all at once. I will comment in bug 493490 that we don't want to abandon the name, but that in general, 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.

  • A "new business" item that we did not have time to discuss in previous meetings was about the impact of the 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 labelled"? But he will open a bug and/or we will discuss at the next meeting. See and comment in bug 501014.
  • 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. [Doug, it is up to you, but I suggest you form a small team of like 3 people, such as Ian and Dani or, others who know some of the technical issues, to help if they are able and willing.] The goal being just a more specific statement of what it means, and what projects have to do differently for Oxygen. That is, we don't need to reach Nirvana in one release cycle.
What would this take? Such as,
features can never be removed but are replaced and transitioned?
I am assuming for Oxygen we want have a "streamless URL" available (not built in) to make it easier for some to start testing the update from Neon to Oxygen. (See bug 483786)
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 users 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 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 would not be updated. (Now it can be, as long as it is named "eclipse.exe").
  • 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

  • Discuss how to deal with Java 9 being moved to July 2017 [Dani]
  • The remaining "new business" items are from previous meetings. I am not sure they resolved so left them for now.
  • Wayne could not make the meeting, but posted a message to our mailing list about concern over some specific projects -- some of which may have to be "removed" from the train. But, in addition, expressed concern over "the process".
- I agree and commented on a similar issue on cross-project list about two projects who "declared intent", but thought they could join the build at the last minute.
- I wondered out loud if it was time for more of a Sim. Release process where projects had to "prove they were ready to be in the Sim. Release" instead of us just saying what they needed to do, and then assume they were doing it. We did not discuss at this meeting, but, for example, I mean like a checklist (web app) that has to be updated every milestone? Just an idea.
  • A question was raised if people have to "announce" they will be in "Neon.1" if they were in Neon. The answer was "no". [Did not mention it at meeting, but they should announce if they are NOT going to be in Neon.1.]
- This led to a brief discussion if projects should "rebuild" if their prereqs change. For example, if a security bug is found in an Orbit bundle. A few thought "yes", but seemed the consensus was "there was no way we could force them to" (i.e. can not leave them out, or else their "previous release" would still be there with the bad bundle) and it was probably a fringe enough case we did not need to have a rule about it.
  • A question was raised how we can avoid issues such as with Neon where Window Builder was excluded for Neon. They were ready at the very very last minute but had not done any builds or testing for all of the Neon development cycle. Somehow, we should "detect" when projects are not active so we can approach them early to find out if the project is viable if they are testing, etc.

Next Meeting

  • November 2, 2016 - Regular First Wednesday Meeting

Reference

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

Back to the top