After some painful conversation with the Planning Council members, the 
conclusion was to delay the release 1 week, but not do a full respin, to 
only revert the EGit contribution. 

The plan is to redo the common repository and EPP packages, with the EGit 
contribution reverted to what it was in SR1, which I believe is identical 
to what it was in RC3. There are a few "technical tricks" I can try to 
accomplish this, so all other projects do not have to do any re-work ... 
just wait until Friday 3/1, before making your releases "visible". 

It was not a easy decision, and arguments made for/against several 
alternatives, but ended up concluding that reverting seemed to be safest 
and least amount of re-work. 

We recognize that many users will be "missing out" on the new features and 
bug fixes contained in the newer EGit versions ... and we know the EGit 
committers have been working hard to improve EGit, which is much 
appreciated ...  but we felt like the community has come to expect the EPP 
Package Service Releases and common update repo to be rock solid. We 
feared that respining with even the "latest" 2.3.1 version (instead of 
2.3.0, which has the data-damaging bug) still carried risk associated with 
'last minute' changes; that it too might have some bad bugs that simply 
have not been discovered yet. Unlikely, but, some risk. End-users who are 
willing too, can always install from EGit's own repository, and hopefully 
can improve the "incremental contribution" process for Kepler, which 
enables more early testing, with a steady ramp down of small changes. 

The GEF and M2E bugs were also discussed. The M2E bug was perceived as a 
bug that could be addressed by the project's own update repo and "hot fix" 
process. The GEF issue is more complicated, can not be fixed by their own 
update site, exactly, since part of the damage already exists in SR1. We 
recommend to them to make their Kepler version be GEF 3.10, since various 
Juno versions will have some 3.9 and some 3.8; the differences in code are 
relatively minor, as I understand it, with the version change being the 
worst, and some adopters will have to work-around that, but it is feasible 
to live with it. 

Apologies for the week delay, I'll keep you updated as Markus and I make 
progress on our fall-back efforts. 

Thanks, 

_______________________________________________
cross-project-issues-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Reply via email to