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.

Simply remove EGit 2.3 from common repo

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 if versioned correctly, EPP packages and "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.