Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Planning Council/February 22 2013"
(→Logistics) |
(→Background) |
||
| Line 141: | Line 141: | ||
=== Background === | === Background === | ||
| − | :: {{bug|400513}}, {{bug|401249}} | + | :: {{bug|400513}}, {{bug|401249}}, and maybe {{bug|400818}}? |
:: [http://dev.eclipse.org/mhonarc/lists/egit-dev/msg03039.html Egit message list] | :: [http://dev.eclipse.org/mhonarc/lists/egit-dev/msg03039.html Egit message list] | ||
:: Numerous posts to cross-project list | :: Numerous posts to cross-project list | ||
Revision as of 13:35, 22 February 2013
Contents
Logistics
| Meeting Title: | Planning Council Conference Call |
| Date & Time: | Wednesday, February 22, 2013, at 1300 Eastern |
| Dial in: | (See Asterisk service for complete details on SIP, potential new numbers, phone mute commands, etc.)
Phone Numbers:
|
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
Juno SR2
- SR2 Recovery Plan
(I've left in the "issues bullet" from last meeting ... to highlight some of the history here).
Background
- bug 400513, bug 401249, and maybe bug 400818?
- Egit message list
- Numerous posts to cross-project list
Alternatives
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