April_02_2014.md
October 9, 2023 ยท View on GitHub
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
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
- Reminder: deadlines and dates for Luna CQs, Reviews, etc.
- Reminder: Make sure you and your projects are aware of these proposals for "preferences and configuration" and "error reporting".
Previous meeting minutes
-
Let's discuss EclipseCon meeting and hear "trip reports" at end
of meeting, if time allows.
[EclipseCon face-to-face](March_16_2014.md)
[Previous "first Wednesday"
meeting](March_05_2014.md)
Kepler SR2
- Any issues?
-
There is one known, mysterious p2-update issue (discovered after 'release'):
Sounds like no progress?
This was discussed at EclipseCon, by p2 team, and while good solution is still unknown, the reasons for it are understood, and (for some reason) doesn't seem to be reported that often as a problem, so I'll remove from future agenda items.
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?
Thanks to Mike and Eclipse Foundation for the steps they are taking to raise awareness. [retrospective] 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?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.
- Brief reminder that some have said if our goal is to "wow casual users" that bugs such as may not allow that. That is, those not used to "EEs" and "toolchains" may be frustrated by some of the behavior, instead of wowed, and those that do understand EEs and tool chains are likely not burdened (too much) by using patches.
- How big is the problem? Who besides Platform (JDT/PDE) has "Java 8" support to patch into Kepler?
-
See - Who has "Java 8 Patch" for Kepler SR2?
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.
-
Note: I've seen where Wayne has already created ["Market Place"
items](https://bugs.eclipse.org/bugs/show_bug.cgi?id=431294#c4)
for the two known cases.
-
Is this equivalent to this "common patch" repo? (I think it
is, mostly)?
- 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.
<!-- end list -->
-
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.
<!-- end list -->
- Konstantin [has proposed to "do all the
work"](https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg10451.html)
to create new packages with patched features, if he had "a
commitment to publish these packages at a reasonable
location in eclipse.org main downloads area".
- Are there "third party" providers that make these sort of
"Kepler Plus" packages? Such as EclispeSource via Yoxos?
(And, I'm not asking for any confidential information\!).
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.]
Results of discussion
''Meeting went over by 30 minutes, so we could talk on this subject for an hour. We did decide a general direction, though some items still needed a bit more research: ''
- If Konstantin was willing to "do all the work", we saw no reason to object to making the "pre-patched" packages available.
- ''But, we did not want to give users the wrong impression that they were "on par" with a service release, since basically they will be untested (by community, and package maintainers) so wanted users to have to go to separate page, make an explicit choice, and know what they were getting, for example to make it clear these were "Kepler SR2 packages with Java 8 Support patches pre-applied". We would not want to call them "SR3" nor imply "Kepler with full Java 8 support". ''
- ''Follow-up Actions: ''
-
\* Konstantin to send note to epp-dev list asking if any
packages did not want to have such a patched package made
available. (package maintainers would not have to test or
sign-off on them, so at worse, they might get some bug reports
they'd have to triage ... which hopefully would be a good thing
as an early warning for Luna issue. And, of course, they could
test as much as they'd like, but there would be no official
"sign-off").
\* Konstantin to send note to "m2e" asking if any inclusion
required/desired for "wtp-m2e" in WTP.
\* David to follow through with Eclipse Foundation, on how and
where to place on "downloads". \[Technically, EF "owns"
downloads page, but they'd appreciate our input and
suggestions.\]
-
\* The best suggestion I heard, came from Dani, where on the
current "Java 8 support" page, to have a link to 1) Kepler
SR2 packages with Java 8 support patches pre-applied and 2)
a link to "Luna packages under development with Java 8
support" (this would be more relevant once M7 comes out ...
but, until then, might point to Eclipse's download page for
I-builds? Or, just say "(coming for Luna M7, available May
9th)".
\* Would recommend a "related link" on normal download page,
that went to "Java 8 support page".
-
\* Konstantin: It needs to be far more prominent that
that (bigger font). The user should be able to glance on
the page and see Java 8 reference quickly. That will not
be the case with the small text of the related links. On
the call, folks brought up two alternatives that would
address my concerns (a) Java 8 tab next to developer
builds tab or (b) Java 8 rectangle beneath Eclipse
Standard banner.
- Non-action items we agreed on:
::* No changes to Kepler Sim. Release repository.
::* No "common patch repository" would be made available.
::* If someone "not ready now", then, we would not go through this again in a month or two. (This includes, for example, if "JDT" comes out with an improved patch in weeks or months ahead, then users would still have to go to their specific site to install that update).
- Open Questions
::* When should the "Java 8 Support page with patched packages" go away? When Luna comes out in June? Or, leave until September and Luna SR1? Seemed a slight leaning towards September ... but ... we did not really discuss enough.
Luna Planning
- Question/awareness of "Mac packaging". See . 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?
There was clear agreement this was not a Luna item, but most agreed it should be investigated for Mars. It might take reaction on some projects, such as if they don't specify "platform URLs" correctly (but use some sort of relative or absolute file paths) but no real blockers are currently known. Need to investigate if any side effects such as does using "dropins" break the signature ... or, does dropins need to be somewhere outside of Eclipse.apps", and similar unknowns.
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 March_24_2013 and for discussion leading to action items, see April_10_2013. For last status update, see May_8_2013.