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/April 02 2014"
m (→Kepler Plus) |
m (→Kepler Plus) |
||
| Line 151: | Line 151: | ||
== Kepler Plus == | == Kepler Plus == | ||
| − | * Discuss/Decide Plan (if any) for "post Kepler patches" for Java 8 support. | + | * Discuss/Decide Plan (if any) for "post Kepler patches" for Java 8 support. |
| + | : I'm assuming everyone has been reading the thread on cross-project list titled: Kepler SR3 for Java 8? | ||
| + | :: For overall view, see https://dev.eclipse.org/mhonarc/lists//cross-project-issues-dev/threads.html | ||
| + | :: I think this is the initial, quiet posting: https://dev.eclipse.org/mhonarc/lists//cross-project-issues-dev/msg10388.html | ||
| + | :: And for some reason, heats up from there. | ||
: Thanks to Mike and Eclipse Foundation for the [https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg10439.html steps they are taking] to raise awareness. | : Thanks to Mike and Eclipse Foundation for the [https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg10439.html steps they are taking] to raise awareness. | ||
| − | * | + | : Overall, I feel I'm responsible for not putting on agenda months ago (but, I know we are all responsible for failure to plan) ... but it appears that Java 8 support caught some people by surprise -- and perhaps we should have thought to coordinate better? |
| + | * How big is the problem? Who besides Platform (JDT/PDE) has "Java 8" support to patch into Kepler? | ||
| + | :: Faceted Projects, from WTP | ||
| + | :: m2e (has already declined to participate, I believe). | ||
| + | :: ObjectTeam? | ||
| + | :: AspectJ? | ||
| + | :: Anyone else? | ||
| + | * What should "we" do (as being responsible for "overall Release Plans")? | ||
:* Alternatives I've heard mentioned: | :* Alternatives I've heard mentioned: | ||
| + | ::* Do nothing, and projects can provide patch features from their own repositories, if they'd like. | ||
::* Kepler SR3, update sim rel repository, respin packages (gather community testing and feedback, and package maintainers testing). | ::* Kepler SR3, update sim rel repository, respin packages (gather community testing and feedback, and package maintainers testing). | ||
::* Some sort of new "R" release? that was apparently discussed at Arch. meeting at EclispeCon? | ::* Some sort of new "R" release? that was apparently discussed at Arch. meeting at EclispeCon? | ||
| − | ::* In addition to | + | ::* In addition to EF's "summary pages", have a common repository that would contain all patches related to Java 8. |
:::* This would, presumably, hold patches for "new function" for Java 8, as well as anyone who had to fix something to enable running on Java 8 -- but not "fixes in general" (those should still come from project's own repositories). | :::* This would, presumably, hold patches for "new function" for Java 8, as well as anyone who had to fix something to enable running on Java 8 -- but not "fixes in general" (those should still come from project's own repositories). | ||
| − | :::* Would be "long lived" in the sense we would not delete it when Luna came out, but would not have any further maintenance done on those patches (i.e., no attempt to make Kepler | + | :::* Would be "long lived" in the sense we would not delete it when Luna came out, but (I'd propose) would not have any further maintenance done on those patches (i.e., no attempt to make Kepler equal Luna support for Java 8). More of a sneak peek. Care is needed here not to give the wrong impression this was "Complete Java 8 support backported" to Kepler. |
:::* This could be implemented as a snapshot: with "copies" of the patch repositories ... composting subdirectories, and remaining unchanged. | :::* This could be implemented as a snapshot: with "copies" of the patch repositories ... composting subdirectories, and remaining unchanged. | ||
| − | :::: Or could be implemented floating: a composite repo pointing to the original patch repositories, so small tweaks or blocking defects fixed (eventually) and thus be "in" the "Common Java 8 Patch Repository" automatically. | + | :::: Or could be implemented floating: a composite repo pointing to the original patch repositories, so small tweaks or blocking defects fixed (eventually) and thus would be "in" the "Common Java 8 Patch Repository" automatically. |
Be prepared for a roll-call vote! Not only "yea or nay" but, also if your projects (with PMC's blessing) had something for this repo, or if the strategic member you represent has any view point to share with the Planning Council. | Be prepared for a roll-call vote! Not only "yea or nay" but, also if your projects (with PMC's blessing) had something for this repo, or if the strategic member you represent has any view point to share with the Planning Council. | ||
Revision as of 23:58, 27 March 2014
Contents
Logistics
| Meeting Title: | Planning Council Conference Call |
| Date & Time: | Wednesday, April 2, 2014, 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
- Reminder: deadlines and dates for Luna CQs, Reviews, etc.
Previous meeting minutes
- Let's discuss EclipseCon meeting and hear "trip reports" at end of meeting, if time allows.
- EclipseCon face-to-face
- Previous "first Wednesday" meeting
Kepler SR2
- Any issues?
- There is one known, mysterious p2-update issue (discovered after 'release'): bug 427148
- Sounds like no progress?
Kepler Plus
- Discuss/Decide Plan (if any) for "post Kepler patches" for Java 8 support.
- I'm assuming everyone has been reading the thread on cross-project list titled: Kepler SR3 for Java 8?
- For overall view, see https://dev.eclipse.org/mhonarc/lists//cross-project-issues-dev/threads.html
- I think this is the initial, quiet posting: https://dev.eclipse.org/mhonarc/lists//cross-project-issues-dev/msg10388.html
- And for some reason, heats up from there.
- Thanks to Mike and Eclipse Foundation for the steps they are taking to raise awareness.
- Overall, I feel I'm responsible for not putting on agenda months ago (but, I know we are all responsible for failure to plan) ... but it appears that Java 8 support caught some people by surprise -- and perhaps we should have thought to coordinate better?
- How big is the problem? Who besides Platform (JDT/PDE) has "Java 8" support to patch into Kepler?
- Faceted Projects, from WTP
- m2e (has already declined to participate, I believe).
- ObjectTeam?
- AspectJ?
- Anyone else?
- What should "we" do (as being responsible for "overall Release Plans")?
- Alternatives I've heard mentioned:
- Do nothing, and projects can provide patch features from their own repositories, if they'd like.
- Kepler SR3, update sim rel repository, respin packages (gather community testing and feedback, and package maintainers testing).
- Some sort of new "R" release? that was apparently discussed at Arch. meeting at EclispeCon?
- In addition to EF's "summary pages", have a common repository that would contain all patches related to Java 8.
- This would, presumably, hold patches for "new function" for Java 8, as well as anyone who had to fix something to enable running on Java 8 -- but not "fixes in general" (those should still come from project's own repositories).
- Would be "long lived" in the sense we would not delete it when Luna came out, but (I'd propose) would not have any further maintenance done on those patches (i.e., no attempt to make Kepler equal Luna support for Java 8). More of a sneak peek. Care is needed here not to give the wrong impression this was "Complete Java 8 support backported" to Kepler.
- This could be implemented as a snapshot: with "copies" of the patch repositories ... composting subdirectories, and remaining unchanged.
- Or could be implemented floating: a composite repo pointing to the original patch repositories, so small tweaks or blocking defects fixed (eventually) and thus would be "in" the "Common Java 8 Patch Repository" automatically.
Be prepared for a roll-call vote! Not only "yea or nay" but, also if your projects (with PMC's blessing) had something for this repo, or if the strategic member you represent has any view point to share with the Planning Council. [As always, the decision is not made by "majority rules" (the decision is made by "status quo, if no consensus") ... but I do want to be sure to hear, equally, from everyone, with specifics.]
Luna Planning
- Question/awareness of "Mac packaging". See bug 431116. My view it is too late to do for Luna -- anyone feel like it's so important we drop other things to do this? I assume could not be done in an "SR" (but, maybe?) ... which would mean "another year". Is there a reason to never do it? (i.e. doesn't fit someone's "use cases" or workflow?) Would that mean we need "two forms" of packaging available to satisfy everyone?
Progress on Action Items
- Improved "aggregator examples/doc". (dw -- no progress).
- [Orbit plan (dw -- no formal progress)]
New Business
- ?
Next Meeting
- May 7, 2014 - Regular First Wednesday Meeting
Reference
- 2013 EclipseCon face-to-face follow-through action items. For original meeting notes, see Planning_Council/March_24_2013 and for discussion leading to action items, see Planning_Council/April_10_2013. For last status update, see Planning_Council/May_8_2013.