Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse.org-planning-council] [cross-project-issues-dev] Fwd: Re: Kepler's final staging repository is complete
> (Just for reference, I tried building "as is" on a local test
> machine and there were errors in unpacking jars from "stardust" I
> think ... could be a problem with my "remote" test build or something ...

To set the record straight, this was a problem with my test machine setup ... I had been experimenting with Java 7, and didn't have it completely reset to a clean/production equivalent state. While some projects (at least one) had intentionally changed their content, I am not sure there were any others ... so, just didn't want to spread false rumors (can there be true rumors? :).
 
Thanks again,




From:        David M Williams/Raleigh/IBM@IBMUS
To:        "eclipse.org-planning-council" <eclipse.org-planning-council@xxxxxxxxxxx>,
Date:        06/13/2013 06:35 PM
Subject:        Re: [eclipse.org-planning-council] [cross-project-issues-dev] Fwd: Re: Kepler's final staging repository is complete
Sent by:        eclipse.org-planning-council-bounces@xxxxxxxxxxx



Thanks all for your quick assessments and advice. I'll prepare a stream that uses current build as input, except for CDO, and get that updated late tonight. And if needed, can do same for Gyrex (or other bad bugs) later. (Just for reference, I tried building "as is" on a local test machine and there were errors in unpacking jars from "stardust" I think ... could be a problem with my "remote" test build or something ... but, also could be evidence that not everyone leave's their repos alone after RC4 :(




From:        Ian Bull <irbull@xxxxxxxxxxxxxxxxx>
To:        "eclipse.org-planning-council" <eclipse.org-planning-council@xxxxxxxxxxx>,
Date:        06/13/2013 06:04 PM
Subject:        Re: [eclipse.org-planning-council] [cross-project-issues-dev] Fwd: Re: Kepler's final staging repository is complete
Sent by:        eclipse.org-planning-council-bounces@xxxxxxxxxxx



Sorry everyone, I'm travelling today.

+1 on the CDO change.  There also appears to be a problem with either the Gyrex or RAP (or the combination). As the Runtime PMC representative, I'll look into these and see how serious they are, why they happened and if I think the Planning Council should react.

I'll look at these tomorrow.

Cheers,
Ian



On Thu, Jun 13, 2013 at 12:40 PM, Steffen Pingel <steffen.pingel@xxxxxxxxxxx> wrote:
+1  

I can't make a call on the severity of the technical issue but trust Eike's and Ed's judgement that the defect justifies a respin.  

Considering that final EPP packages have not been tested, yet, the unfortunate additional effort should be as minimal as possible at this point and considering the time left until the release the risk involved in a rebuild is still manageable.

Steffen



On Thu, Jun 13, 2013 at 9:06 PM, Ed Merks <ed.merks@xxxxxxxxx> wrote:
Esteem Council Members,

I'd like to ask for an exception to respin CDO's contribution to the release train.  Eike has an exemplary record for contributing well formed contributions to the train, so I think we should accept his final contribution which he believes is necessary for CDO clients to receive a quality release in Kepler.

Regards,
Ed


-------- Original Message --------
Subject:
Re: [cross-project-issues-dev] Kepler's final staging repository is complete
Date:
Thu, 13 Jun 2013 17:46:02 +0000
From:
Pascal Rapicault <pascal.rapicault@xxxxxxxxxxxx>
Reply-To:
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
To:
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>




I'm not involved in the actual process that makes the various builds happen, however I would like to vote for a rebuild to happen to give him a chance to get his changes in.

If we can't do changes, then why don't we release now?

Pascal

-----Original Message-----
From: cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Eike Stepper
Sent: June-13-13 1:42 PM
To: cross-project-issues-dev@xxxxxxxxxxx
Subject: Re: [cross-project-issues-dev] Kepler's final staging repository is complete

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 <stepper@xxxxxxxxxx>
> To: cross-project-issues-dev@xxxxxxxxxxx,
> 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-bounces@xxxxxxxxxxx
> ----------------------------------------------------------------------
> --------------------------------------------------
>
>
>
> 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
>
> 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://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/
>>
>> The final repo-reports are available at the usual place:
>>
>>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#Plann
>>ing_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
>>
>> Thanks everyone. Good luck with your final testing and wrap-up.
>>
>>
>>
>> _______________________________________________
>> cross-project-issues-dev mailing list  
>>cross-project-issues-dev@xxxxxxxxxxx
>>https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>
>
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
>
>
>
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>

_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev




_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev




--
Steffen Pingel
Principal Software Engineer, Eclipse Mylyn
Mylyn Tasks Lead
http://tasktop.com

_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council

IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation.  To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.



--
R. Ian Bull | EclipseSource Victoria | +1 250 477 7484
http://eclipsesource.com | http://twitter.com/eclipsesource _______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council

IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation.  To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal. _______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council

IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation.  To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.

Back to the top