February_22_2013.md
October 9, 2023 ยท View on GitHub
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
width="100%" valign="top" |
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
width="100%" valign="top" |
|
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
-
, , and maybe ?
[Egit message
list](http://dev.eclipse.org/mhonarc/lists/egit-dev/msg03039.html)
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 (No "perfect fix", even if we did a respin, due to version number snafu even in SR1) M2E (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.
Summary
- The most agreed-to item was should not ship as-is.
- Second most agreed-to item was a full respin was too risky and too much time delay.
- The M2E and GEF bugs are bad (especially the GEF version snafu) but felt they were not stop ship bugs, and respin for them not required. Though it was recommend GEF move to "3.10" for Kepler, since various Juno distributions will end up with a mix of 3.8 and 3.9.
- GEF's issue was related to having multiple releases in the same repo, but specifying only "minimum requirement" in aggregation files. Everyone likely needs a refresher on importance (and syntax) of making contributions very specific ... and testing early. Just because your component is correct, doesn't mean repo or EPP package is.
- The EGit problem was discussed the most; pros and cons to "moving up" to 2.3.1 and re-spinning, or revert to SR1 or some point before their RC4 update. Pros were lots of fixes improvements have been made. Cons were there is still risk in last minute changes to such and important piece of Eclipse.
- Historically, we (PC) started off saying maintenance releases were bug fixes only (changes in service field only), but "loosened" the rules to accommodate projects that did frequent releases and desired to get their latest code to Eclipse users -- a noble and desirable goal.
- PC probably needs to "tighten rules" about minor updates in maintenance releases ... say, must be in by RC1, at a minimum. Perhaps as much as "released at least one month before RC1" even?
- EGit probably needs a "refresher course" on the value of the Simultaneous Release rules/procedures ... advantages of incremental contributions, having a cool-off or ramp-down process. (Mike volunteered Wayne to help :)
- dw will explore easiest way to revert the repo: alternatives are to try and use the p2.remove task to remove just EGit/JGit features/bundles from the SR2 specific repo (and then EPP process would pick up what was in SR1); if that doesn't work the "make an aggregate repo from the aggregate repo" should do the trick ... just more "search and replace" in a branch of the contribution files, and time to literally respin.
- Once new repo is done, Markus's existing process for spinning EPP packages will be ran.
- Goal was to finish new repo on Monday (or, Tuesday, if complicated). EPP packages on Tuesday (or Wednesday). Some extra eyes/sanity checks Wednesday (or Thursday). Allow mirrors to repopulate, and make "GA" on Friday morning.
- Ian volunteered use of his "p2 diff" tool to compare repos.
- [After meeting, Matthias Sohn said, in message to cross-project list, that "SR2 RC3 contains EGit 2.2.0 [1] which was released in December and SR1 contains EGit 2.1.0". But, still, RC3 is late to change a minor version ... especially now that "trust" is weakened ... but assume its a little bit more stable? if "pure removal" works I'd prefer that, since easier and more predicable. If not, I'll look around and ask others if they feel 2.2 has gotten enough exposure -- but, that solution requires the "make an aggregate from the aggregate" approach ... and still lightly tested by package maintainers.]
- The trade off on "meeting schedule" vs. "quality release" were discussed and I reminded all the importance of our timely releases are not so much for us, or even the Eclipse community, but that commercial adopters make their product plans based on our dates, so any delays introduced by us starts to cost real money to them (rescheduling tests, and what ever else) ... but, agreed that "software industry" is used to such problems and normally buffers in plans can accommodate a one week slip for data-damaging bugs, and a one-time slip of maintenance release should not hurt our trustworthiness to deliver when we say we will.
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 . 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