Skip to main content
Jump to: navigation, search

Planning Council/February 22 2013

< Planning Council
Revision as of 12:41, 22 February 2013 by David (Talk | contribs) (Provide a 4th "composite" to Juno SR2)


Meeting Title: Planning Council Conference Call
Date & Time: Wednesday, February 06, 2013, at 1200 Eastern
Dial in: (See Asterisk service for complete details on SIP, potential new numbers, phone mute commands, etc.)

Phone Numbers:

  • Ottawa (local call in Ottawa) 1-613-454-1403
  • North America (toll free) 1-877-369-7806
  • 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
For all phone lines: Participant conference extension: 710 then enter pin 35498
  • SIP clients:
call, then enter pin 35498.

Members and Attendees

PMC (and Strategic) Reps
Chris Aniszczyk Technology (PMC)
John Arthorne Eclipse (PMC)
Steffen Pingel Mylyn (ALM) PMC
Brian Payton Datatools (PMC)
Doug Schaefer Tools (PMC)
Adrian Mos SOA (PMC)
Ed Merks Modeling (PMC)
Ian Bull Rt (PMC)
David Williams WTP (PMC) (appointed Chair)
Gary Xue Birt (PMC)
Wayne Beaton Eclipse Foundation (appointed)
Strategic Reps
Cedric Brun OBEO (Strategic Developer)
Neil Hauge Oracle (Strategic Developer)
Kaloyan Raev SAP AG (Strategic Developer)
Igor Fedorenko Sonatype (Strategic Developer)
Markus Knauer Innoopract (Strategic Developer)
Achim Loerke BREDEX (Strategic Developer)
(PMC rep) Actuate (Strategic Developer) X
(PMC rep) IBM (Strategic Developer) X
[no name] CA Inc. (Strategic Consumer) 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

Juno SR2

  • SR2 Recovery Plan

(I've left in the "issues bullet" from last meeting ... to highlight some of the history here).


bug 400513, bug 401249
Egit message list
Numerous posts to cross-project list


Please come prepared to discuss alternatives

Does anyone know of any impact of delays to strategic members that might effect choices?
Impact to the projects you represent on ability to do the re-work if needed?

Do nothing

let EGit provide updated project repo with fix
Pro: easy
Con: EPP users especially get the bad bug right away ?and could damage data? before applying the fix

Simply remove EGit 2.3 from common repo

thus effectively reverting to their 2.1 in SR1, re-spining EPP packages, allow to re-mirror, etc.
Pro: moderately easy -- assuming I could do the p2.remove script to remove just their bits (not a certainty)
Con: EGit starts off pretty far behind

Full respin cycle

Turn on the aggregator, let people update their contributions so it runs, hope we get same content, respin EPP, re-test, etc.
Pro: best quality
Con: would take 2 weeks (IMHO), sounds like several projects would want to contribute new bits, lots of work for all participants
Other bugs mentioned as desired in a respin, if we did one. Please comment in these bugs if you have questions/suggestions for them.
GEF bug 401477 (No "perfect fix", even if we did a respin, due to version number snafu even in SR1)
M2E bug 400520 (They will effectively be providing an SR2a, it sounds like, even if we don't respin)

Provide a 4th "composite" to Juno SR2

Would have only EGit in it. Assuming all was versioned correctly, EPP packages and "end-user updates" would find their latest ones
Pro: moderately easy, with minimal work from other projects.
Con: The "bad bits" would still be in repo and theoretically installable, if someone happened to deliberately pick an older version

Do a "branched respin"

In the past, we did a respin once to remove some invalid, non-approved third party code (so, "bad bits" could not stay, even if "not most recent").
In short, means creating a branch of b3 contribution files, me changing everyone's URL to point to the current, specific SR2 site, except for those that are allowed to contribute to a respin (which would end up pointing to what ever they say is corrected).
Pro: more assured of getting same bits as before, yet having a "clean" SR2 repo (instead of "bad bits" intermingled).
Con: maybe more work for me (will have to study scripts to find where "branch" is specified). Still need to respin EPP, due minimal test or "compare" to make sure only what was intended to change did in fact change.
We would still need to decide "who gets to participate".
I'm most concerned about GEF's versioning problem, since no way to fix that after released ... no way to "go down" in version numbering ... adopters can "work around" if they have a full fledge, new "product", but not if just providing new features/plugins or updating an existing product.

Other Alternatives?

Issues (from previous meeting)

EGit planning 2.3, but 2.1 is still their common repo contribution? (That is, why aren't they "fully participating"?) See bug 399437. Kepler contribution is even further behind.
Action Item: Chris will "get back to us" on what EGit's plans are ... he initially thought "final code" would be done in two weeks, but I reminded him RC4/final builds are next Wednesday.

Next Meeting

  • March 6, 2013


Kepler Wiki page
Juno Wiki page
Planning Council/Indigo retrospective
Planning Council Members
Simultaneous Release Roles and Simultaneous Release Roles/EMO

Back to the top