Difference between revisions of "Planning Council/February 03 2016"

Revision as of 14:56, 4 February 2016

Logistics

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

• Welcome Alexander Nyssen as new Planning Council member representing Itemis.

• Any others?

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?
• Tracking participation in minor releases bug 485223

Neon Planning (and beyond)

• Should we change "maintenance" staging name now? for Mars.2? See bug 483475.

- [See also bug 483786 for unreleated additional URL.]

- Still "todo" item. (i.e. not done yet, apologies for delay)

• Release Policy vs. Release mechanics. This is being tracked in bug 483322.

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, it sounds like it solves the issue of updating non-root features (as long as they are "in the repository"?).

We had a constructive discussion about this issue, even if not complete agreement. We, at least, have some items to investigate.

- Markus will propose to EPP packages that they (or, he) begin building EPP packages with their "main features" in EPP products as "root features". Thus, if we updated the Sim. Release repo, users would get a "fix" via "check for update". Note: I believe projects would have to come out with a new "release" of the features -- that is "patch features" would not automatically be found -- I THINK. Another implication is that "check for updates" would take longer, I believe, since more features to "fetch" to see if they have changed.

- With the above root features in place, it would be easier to do an off-schedule re-build of the Sim. Release repository -- with just the "changed features" being used as input. We would not rebuild the packages, just the repository. This should minimize the amount of work required from other projects.

- The issue for which there was still disagreement is how to manage these off-schedule changes. I think there are basically three proposals, and we agreed that by next meeting we would list "pros and cons" of each:

* A. Status quo: even if not a recommended practice, projects can add "reference repositories" when their feature is installed, so their users can get easy updates when ever and what ever the project desires. No Planning Council involvement.

* B. Provide a "built-in" URL, disabled by default, that would point to a composite repo named something like "hotfixes" or simply "fixes" or perhaps even "extras" -- depending on the policy that was adopted. The argument being that then at least "what projects do there" is a little more visible. Minimal Planning Council involvement.

* C. Provide a process, and make it easier, for projects to contribute off-schedule "service" and re-spin the Sim. Release repository. This would likely be a special repository, where only the "changed bits" would be included, and the rest point to the previous, unchanged repository (a "trusted repository" in b3 aggregator terminology). The Planning Council would briefly review these "requests for off-schedule builds" primarily to make sure they were "blocking" or "critical" bugs, and perhaps to briefly assess if there was any chance of impacting other projects. i.e. a change in a "leaf" project or a "leaf" function would be pretty easy to "approve", but if someone wanted to make a big change to the way "jobs" worked, then it would take more review and/or testing (if allowed at all).

• 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 bug 483786 is implemented.

Seemed to be no objection to "trying it" and with Neon we will "try it" by having the "streamless-URL" proposed in bug 483786. 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
• Per bug 485861 Oxygen was approved as the name for the 2017 Simultaneous Release.

EclipseCon Face-to-face

• Joint meeting with Arch. Council.
• Participate on EclipseCon2016/Councils_Face-to-Face.
• Suggest times on doodle poll. Thursday, March 10

New Business

• Great Fixes for Neon

Wayne outlined his proposal for "great fixes" for Neon. It is desired the winners (3 or so per milestone) be announced concurrently with M6 and M7. He believes he can automate, via Git, the task of finding non-committers who have made a lot of contributions to one or more projects at Eclipse, for Neon. He would like to identify about 10 candidates, and then have Architecture and Planning Council members vote on who had the "most impact". There was no disagreement with this approach, and the PC members thought they would have time to participate. Details remain to be worked out.

Next Meeting

• March 2, 2016 - Regular First Wednesday Meeting (The week before EclipseCon!)

Reference

Neon Wiki page

Planning Council Members

Simultaneous Release Roles and Simultaneous Release Roles/EMO