September_02_2015.md
October 9, 2023 ยท View on GitHub
Logistics
Meeting Title: |
Planning Council Conference Call |
Date & Time: |
Wednesday, September 2, 2015, 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 meeting, but if questions or issues with previous minutes, this would be a good time to bring them up.
Mars Planning
- Any issues?
- How is the "minor releases" in Mars.1 update going?
-
- From the little I've seen, no radical change, but some change. - Some just being "more honest" about it (that's good). - Have seen the issue where changing "provisional API" to "API" is reason for the minor bump
But, this can be "breaking" for anyone who was trying to use the provisional API (depending). Should we give any guidance in this area?- Have seen where "new features" would break translations.
Should we give any guidance in this area?- I see where WTP is adding a "controversial" feature (but, just controversial "if its ready").
That is, nothing violates Planning Council rules.
-
*Wayne reported there had been about 6 release reviews for minor
releases.*
Neon Planning
- See initial working draft of plan at Neon/Simultaneous_Release_Plan.
- Continuing Discussion of if and how to change "yearly release"?
- * - See "design" wiki page, which acts as centralized place to document the main ideas and plans. * - Rough scheduling alternatives ... what do we want to accomplish?
-
* Current
\- June (3) September (5) February \[(4) June\]
-
* Current plus one (equally spaced)
\- June (3) September (3) December (3) March \[(3) June\]
-
Advantage; similar to current
Disadvantage: hard and bad to release in (mid) December?
-
* Equally spaced (based on May)
\- May, (3) August, (3) November, (3) February \[(3) May\]
-
Advantages: predictable; each roughly 2, 6 week milestones
Disadvantage: arbitrary?
have to work around Thanksgiving holiday
-
* quick plus long
\- June, (2) August, (5) January, (2) March \[(3) June\]
-
Advantage: can have quick "service" after main releases,
those features/projects that "just barely missed" main release
points (June and January) won't have long to wait.
-
Disadvantage: does not easily map to 6 week milestones
still has as long period (5 months) of "no releases"
but, that long period can be good for committers -- to have long
period to focus on one stream.
- Any new requirements?
-
* In "signing section", I would like to add that jars that are already signed, must not be re-signed.
It messes up pack200 "conditioning"
- Discussion of the timing of an extra update release
-
- End result was the direction should be
June (3) September (3) December (3) March \[(3) June\]
-
- General agreement to keep June as the month for the main (major) release
\- Partially just to keep with long tradition -- long enough it is an ingrained expectation from community. \- Partially to fit better with the naturally occurring "summer down time" due to vacations and holidays.
-
- Rough agreement that the goal of an extra update release was to solve the problem of new projects and new features joining the train.
\- The problem of individual projects needing to roll-out important fixes "off schedule" is not addressed by having an extra release, and should (probably) be addressed by changes in EPP packaging or perhaps only the Sim. Release repository (which, would require some change in EPP "features", but avoid "all new" downloads).
- - There was some discussion of having, say, the 1st and 3rd updates be "service only", and middle (December-ish) update release be "minor upgrades", but in general, thought that would be confusing, restrictive, and would not solve main problem of "getting function out to users".
-
- Another strong candidate for "rhythm" was to stick with the current 3 per year, but move the September one, to October, so there is more balance of "waiting period" between update releases (4 months each, instead of current 3 months and 5 months).
\- It was thought this would not work well for Neon updates, since we want a September release that matches Java 9 release (which is currently scheduled for September 22 - <http://openjdk.java.net/projects/jdk9/> ). \- Also some mentioned easier for adopters and contributors to work based on a quarterly schedule.
- - It was explicitly decided to leave Mars as-planned (that is, Mars.2 in February, not December) partially since many plans based on that already, and partially to allow more issues to be ironed out, and partially to allow time to improve testing of Sim. Release repository -- such as to add "API Tooling checks".
-
- Wayne took as a "to do" item, to check with IP staff if a CQ deadline should be set for update releases.
\- Cons (probably not needed): there are few new ones, every one knows the limits \- Pros (would be helpful): helps set expectations of committers and new contributors on how much can be done, by when. - (Though, still varies a lot, if "all new" large contribution, vs. piggy back CQ)
- - Another issue to carry is effect on translations. Both those done by Babel, and those done by adopters. Should we try to get projects to document changes to PII? Are there any tools in Babel that could "diff" what has changed?
- - Another issues to carry is what guidance (or rules) to mention about "changing API". In particular, should "provisional API" be treated as API, or non-API? Some quick remarks was "there is not much we can do ... if doesn't impact train projects ... would be up to each project to decide, and up to adopters to follow closely". Can we do better?
- - There was a brief discussion of if more "parallel streams" would help. That is, currently the "culture" at Eclipse is primarily to work on new features after one release, for the next update release. But, in general, overlapping work efforts and releases might suit some teams better. (Such as, after June, could work on new features for December, putting minimal effort into September release -- and while teams can "do this on their own", would there be advantages (or need) to having a coordinated effort -- involving several "coordinated release repositories" for teams to contribute to early? -- Some mentioned projects do not have enough resources to do that much work?
- - Speaking of resources, it was also mentioned that the "4 releases per year" would be more effort for projects (committers) since even if they do not contribute to a update release, they should still test their stuff with each new update. Improved automated testing might help some, with this.
New Business
- ?
Next Meeting
- October 7, 2015 - 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.