Skip to main content
Jump to: navigation, search

Planning Council/March 02 2016

< Planning Council
Revision as of 17:50, 1 March 2016 by David williams.acm.org (Talk | contribs) (/* Mars "left over" topics)

Logistics

Meeting Title: Planning Council Conference Call
Date & Time: Wednesday, February 3, 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.)

For all phone lines: Participant conference extension: 710 then enter pin 35498
  • Ottawa (local call in Ottawa) 1-613-454-1403
  • North America (toll free) 1-866-569-4992
  • Germany (local call anywhere in Germany) +49-692-2224-6059
  • France (local call anywhere in France) +33-17-070-8535
  • UK (toll free) 0800-033-7806
  • Switzerland (local call anywhere in Switzerland) +41-44-580-2115
  • SIP clients:
call 710@asterisk.eclipse.org, then enter pin 35498.

Members and Attendees

PMC (and Strategic) Reps
Martin Lippert Cloud (PMC)
Chris Aniszczyk Technology (PMC)
Dani Megert Eclipse (PMC)
Sam Davis Mylyn (ALM) PMC
Brian Payton Datatools (PMC)
Doug Schaefer Tools (PMC)
Ian Bull Rt (PMC)
Chuck Bridgham WTP (PMC)
Wayne Beaton Eclipse Foundation (appointed)
David Williams (appointed Chair) Y
Strategic Reps
Alexander Nyssen Itemis
Nick Boldt Redhat (Strategic Developer)
Remi Schnekenburger CEA List (Strategic Developer)
Cedric Brun OBEO (Strategic Developer)
Neil Hauge Oracle (Strategic Developer)
Stephan Merker SAP AG (Strategic Developer)
Markus Knauer Innoopract (Strategic Developer)
(has PMC rep; Dani Megert) IBM (Strategic Developer) X
Inactive
[no name] CA Inc. (Strategic Consumer) X
(was Gary Xue) Birt (PMC) X
(has/had PMC rep) Actuate (Strategic Developer) X
(was Rajeev Dayal) Google (Strategic Developer) X
Ed Merks Modeling (PMC) X
Adrian Mos (Marc Dutoo ) SOA (PMC) X

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 Martin Lippert as new Planning Council member representing Cloud PMC
  • Don't forget about EclipseCon face-to-face on Thursday, March 10. Time?
Wayne to arrange "google talk" connection?
  • 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

Mars "left over" topics

  • Requirement to use "latest Orbit" (or other pre-reqs) even in Maintenance releases
Turns out, some projects "do not rebuild, ever, for "maintenance" so they do not use the latest Orbit.
Is it too much to *require* that they rebuild to "pick up" new prereqs? See bug bug 487285 for why this is important. (Ideally, "new builds" with "new prereqs" would be easy to do. But, guess not always, if not used to branches, I assume.)
  • The composite .../releases/mars contains "contradictory" information with respect to some platform filters. See bug 488725. That is, each repository is internally consistent, but not when "combined". As far as I know, this particular case would never impact end-users. Assuming that is true, I see no reason to do more to that Sim Rel repository.
But, would have been nice to detect earlier. The b3 aggregator might help for the general case, but do not think it would have in this case. That "noenv" filter is a Tycho or e(fx)clipse specific "trick".

Neon Planning (and beyond)

new business

  • I also expected "emf-facets" to request an exception -- but have not seen it yet. They "announced early" (before M4) but have not yet been in a build. In some bugs and email I requested they "follow the Exception process".
  • EPP will create M6 with most features being root features. Deserves some good testing. (But I am not sure of the best way to do that).
  • I have proposed and in the process of, moving "Sim Release Tests" to CBI -- the main goal being to encourage individual projects to do more of that same testing during their own builds.
  • I have proposed and in the process of, moving "b3 aggregator" to CBI. Here the goal is mostly to improve its long-term support.

old (ongoing) stuff

  • 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).

Oxygen Planning

  •  ?

EclipseCon Face-to-face

New Business

  • Nick suggested moving b3 editor to Gerrit to facilitate contributions and evolution of b3
David vetoed that change as being "not worth it (at this point in time)" according to him.
  • 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

  • EclispeCon face-to-face
  • April 6, 2016 - Regular First Wednesday Meeting

Reference

Neon Wiki page
Planning Council Members
Simultaneous Release Roles and Simultaneous Release Roles/EMO

Back to the top