Hi Eike, you've CC'ed me, but removed cross-project... ;-) (No need to CC: me... if I am watching a mailing list, then it is cross-projects!)
Yes, I can confirm that org.eclipse.emf.cdo and other CDO features are included in the modeling package. From the top of my head I'd say that this is the only package that is affected. Regards, Markus On Thu, Jun 13, 2013 at 7:41 PM, Eike Stepper <[email protected]> wrote: > Am 13.06.2013 19:10, schrieb David M Williams: > > Eike, as much as I like to be accommodating, this doesn't sound like a >> respin everything candidate. Is there a way to >> make this available as a feature patch from your own project repo, so >> your users could get it immediately upon 6/26 >> release? >> > > I have no clue how to deal with feature patches. The only viable > alternative to a respin would be to offer a maintenance build immediately > after the build. But you know how many users just rely on what's in the > train... > > > Does this impact any/many EPP packages? >> > > I think that only the Modeling package would be affected. I've cc'ed > Markus. > > > > If so, which ones, and what are "effects". How many users (use-cases) >> would be >> effected? >> > > Unfortunately all CDO users would be affected. The effect is that whenever > a CDOSession to a server is closed (usually at application exit time, but > sometimes more often before that) and one of the frequent server > notifications arrives, it causes a delay of 10 seconds. This is arguably > not an all-data-is-lost kind of bug but certainly very annoying. > > In addition not even the original bug is fixed now and that can (and did, > as reported late by users) cause an application (i.e., it's CDOSession to > hang from beginning if the server messaging load is high). > > These two aspects together made me realize that I absolutely don't want to > ship CDO in this state. > > > From my quick skim read of the bug, it sounds like a performance >> regression that would not impact too many users ... >> but, I'm willing to listen to other arguments for why it should be >> considered "blocking" and why it might justify >> repining everything. >> > > Please see above. > > I'm not sure whether it's about the extra effort (I'll offer beer at next > EclipseCon!) or about not fostering bad precedence - if there's the least > bit of a chance, please be soft on me ;-) > > > Cheers > /Eike > > ---- > http://www.esc-net.de > http://thegordian.blogspot.com > http://twitter.com/eikestepper > > > > >> Thanks for bringing it to our attention, in either case. >> >> >> >> >> From: Eike Stepper <[email protected]> >> To: >> cross-project-issues-dev@**eclipse.org<[email protected]> >> , >> Date: 06/13/2013 12:10 PM >> Subject: Re: [cross-project-issues-dev] Kepler's final staging repository >> is complete >> Sent by: >> cross-project-issues-dev-**[email protected]<[email protected]> >> ------------------------------**------------------------------** >> ------------------------------**------------------------------ >> >> >> >> >> Hi All, >> >> It's totally embarrassing but a user's have just reported that I made a >> fatal typo in a last minute fix. I fear we can't >> ship with this typo in place. Is there any chance to get a contribution >> into Kepler with a fix to this fix? >> >> The bug that was found late and that I fixed two days ago is: >> >> 410409: CDOClientIndications can arrive before session is fully active >> https://bugs.eclipse.org/bugs/**show_bug.cgi?id=410409<https://bugs.eclipse.org/bugs/show_bug.cgi?id=410409> >> >> Instead of checking for LifecycleState.ACTIVATING I wrote DEACTIVATING in >> a moment of pressure and unconciousness: >> >> if (session.getLifecycleState() == LifecycleState.ACTIVATING) >> { >> LifecycleUtil.waitForActive(**session, 10000L); >> } >> >> That not only doesn't fix the (timing-related, hard to test) original >> problem, worse, it tends to add 10 second delays >> in other situations. I already wondered why our tests took so much longer >> than usual, but I blamed the build server load >> during the last contribution opportunities ;-( >> >> I'm very sorry for the inconvenience that I might cause!!!!!!!! >> >> Cheers >> /Eike >> >> ---- >> http://www.esc-net.de <http://www.esc-net.de/> >> http://thegordian.blogspot.com >> <http://thegordian.blogspot.**com/<http://thegordian.blogspot.com/> >> > >> >> http://twitter.com/eikestepper >> >> >> >> >> >> Am 13.06.2013 00:36, schrieb David M Williams: >> >>> Here we are, at (near) the end of RC4 already! EPP packages will be >>> complete in a day or two. >>> Everyone, and especially anyone who pushed changes late in the day, >>> should confirm the staging repo contains what you >>> expect it to. >>> >>> http://download.eclipse.org/**releases/staging/<http://download.eclipse.org/releases/staging/> >>> >>> The final repo-reports are available at the usual place: >>> >>> http://build.eclipse.org/**simrel/kepler/reporeports/<http://build.eclipse.org/simrel/kepler/reporeports/> >>> >>> For those of you with "missing legal files" ... it is between you and >>> the EMO if they will grant an exception for the >>> release. >>> I know of only one project that as requested it (bug 401273). >>> >>> As for other things, such as unsigned jars, technically you should work >>> with your PMC and planning representative to ask >>> for exceptions, >>> but suspect if you have not done so by now, it's simply a matter that >>> you don't care. But, if you do, the reference is >>> http://wiki.eclipse.org/**SimRel/Simultaneous_Release_** >>> Requirements#Planning_Council_**Exception_Process<http://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements#Planning_Council_Exception_Process> >>> Beyond that, I'll leave it up to the rest of the Planning Council to >>> raise objections if they think any violations are >>> so egregious it deserves discussing whether or not to included in the >>> common repo. >>> >>> Remember that as we enter "quiet week" we do NOT promote the builds to >>> their usual place, since to do so is basically >>> making the release available early. >>> The purpose of "quiet week" is partially to allow adopters to do final >>> acceptance testing, but to also serve as a buffer >>> in case a build is required -- but, rebuilds are very risky, and rare, >>> so has to be an especially bad bug (such as one >>> which prevents install or update from working, or perhaps where one >>> project prevents another project from working). >>> Otherwise, the extra time is for projects to prepare "hot fix" feature >>> patches to be available from their own project >>> repositories. >>> >>> If you like to read wordy, but possibly educational, documents, don't >>> forget about >>> http://wiki.eclipse.org/**Kepler/Final_Daze<http://wiki.eclipse.org/Kepler/Final_Daze> >>> >>> Thanks everyone. Good luck with your final testing and wrap-up. >>> >>> >>> >>> ______________________________**_________________ >>> cross-project-issues-dev mailing list >>> cross-project-issues-dev@**eclipse.org<[email protected]> >>> https://dev.eclipse.org/**mailman/listinfo/cross-**project-issues-dev<https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev> >>> >>> >> ______________________________**_________________ >> cross-project-issues-dev mailing list >> cross-project-issues-dev@**eclipse.org<[email protected]> >> https://dev.eclipse.org/**mailman/listinfo/cross-**project-issues-dev<https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev> >> >> >> >> >> ______________________________**_________________ >> cross-project-issues-dev mailing list >> cross-project-issues-dev@**eclipse.org<[email protected]> >> https://dev.eclipse.org/**mailman/listinfo/cross-**project-issues-dev<https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev> >> >> -- ### EclipseSource Group Telefon: +49 721 664733-0 (GMT +2) Telefax: +49 721 66473329 http://eclipsesource.com Innoopract Informationssysteme GmbH Lammstrasse 21, 76133 Karlsruhe Germany General Manager: Jochen Krause Registered Office: Karlsruhe, Commercial Register Mannheim HRB 107883
_______________________________________________ cross-project-issues-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
