January_06_2016.md
October 9, 2023 ยท View on GitHub
Logistics
Meeting Title: |
Planning Council Conference Call |
Date & Time: |
Wednesday, January 6, 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
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 the meeting, but if questions or issues with previous minutes, this would be a good time to bring them up.
Mars Planning
- Mars.2 issues?
- Remember Mars.2 RCs begin Jan 15 to Jan 22.
- Tracking participation in minor releases
Neon Planning (and beyond)
- Our Neon Plan is now official.
- Should we change "maintenance" staging name now? for Mars.2? See .
- - Since "Nick votes for soon", I will ask: "Any objections"?
- ''No objections. And one "good idea since is currently confusing". I will look into implementing and see what breaks. :) ''
- - [See also for unreleated additional URL.]
- Release Policy vs. Release mechanics. This is being tracked in .
-
One proposal: have all features in EPP packages be "root features" and establish a procedure of adding new code to the Sim. Release repository "at any time" (or, say, once per month?) -- say for "hot fixes" only ... say after review/approval by Planning Council? AND, to avoid "contamination" of update site lists (without the user being in charge of it) change p2 install/update to not allow the addition of reference repositories during feature installs. But, it has been stated, adopters still want that ability ... so, not sure how "we" could ever know the difference.
Perhaps could solve with a "product preference" so EPP could "set" the preference one way, and adopters creating products could set it another way? Or, direct users to do so? - Easy for me to say "change p2" :) but ... who would do the work? Perhaps solve simply with a "policy" of "do not add reference repositories" (with feature installs)? - But without some way to enforce it, I think some projects still would. This "reference repositories issue" was a discussed as a concern at Architecture Council - Apparently there have been cases of users getting "mixed" installs because reference repositories are sometimes very broad. \[I hope I've captured the issue correctly, I was not there, so please correct if I read it wrong.\]Does Oomph solve this problem at all? Does it have a possible solution?
From [Ed's note to ide-dev list](https://dev.eclipse.org/mhonarc/lists/ide-dev/msg01043.html), it sounds like it solves the issue of updating non-root features (as long as they are "in the repository"?).
- Appears there is little consensus on "what the problem is" and even less on "how to solve". There was a consensus that "users get bad bugs fixes quickly" and "users should not need to know a lot to get them", but other than that little consensus. It is believed that not all projects who use "reference repos" use them for the purpose of "hot bug fixes" and some may use for "anything". Are "reference repos" all that bad? (Those that produce "products" can "work around" the problem by "stripping out" that part of the content metadata they mirror.) Is there "another way" that is feasible, from a technology/manpower point of view. Discussion to continue. I do think current situation and many proposals are a little too "wild west" (uncontrolled) for Sim. Release) but a well-controlled method/procedure will take work.
- Rolling "release" issue.
-
I have sometimes heard it suggested we allow more of a
"continuous release". Is this something we should discuss?
Should we have some long term planning for it? Such as, what
would it take to accomplish that?
This could be planned with or without the "beta stream"
mechanisms sometimes discussed.
- '' Did not discuss much during this meeting, other than to note similarity to above issue.''
- Should the ability to update from yearly release to yearly release be a 'requirement'?
-
What would this take? (Such as features are never "just removed"
but are replaced or transitioned?)
What testing would projects have to do?
May become "defacto requirement" once is implemented.
- Seemed to be no objection to "trying it" and with Neon we will "try it" by having the "streamless-URL" proposed in . For Neon, we will not use that URL automatically anywhere but users can add it if they would like. Will be interesting to see if many bug reports occur from people trying that "update to next main release" (that is, from Mars to Neon).
Neon + 1 Planning
- How's "naming" coming?
- Poll: https://www.eclipse.org/neon/planning/poll.php -> http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_dd4ff581da35bddc
- Current winner (with 242 total votes) and 8 days left: Oxygen
Not quite a "majority", last I looked, but guess that is supposedly the advantage of the voting method used. (Sort of an automatic "runoff", conceptually.)
EclipseCon Face-to-face
- Joint meeting with Arch. Council.
- Participate on EclipseCon2016/Councils_Face-to-Face.
- Suggest times on doodle poll.
New Business
- ?
Next Meeting
- February 3, 2016 - Regular First Wednesday Meeting