Re: [cross-project-issues-dev] Kepler's final re-staging repository is complete

[Eike Stepper]

Am 14.06.2013 04:31, schrieb David M Williams:

_http://download.eclipse.org/releases/staging/_

After review from the Planning Council, I have respun the staging repository, 
with just the CDO contribution
contributing anything new. For everyone else, I used the previous staging build as 
"input" for your contributions, so
would expect identical contents (which, it turns out, is not quite the case).

The new CDO files are as listed at the end of this note ... I hope that's what 
you were expecting ... more features
changing than plugins!


I've checked the list below carefully and it is exactly what it should be: The plugin with the one-token-change, its 
pack.gz and its source plugin. The features are exactly those that include these plugins and I've double-checked that 
the new aggregation (#592) has properly picked them up. For CDO everything is fine now.


I'd like to express again how sorry I am that this happened and how happy I am for all your support in this ugly 
situation. Our team and our contributors have spent one year to resolve 215 bugzillas and come up with the best CDO 
ever: http://download.eclipse.org/modeling/emf/cdo/drops/R20130613-1157/relnotes.html


Our users will certainly appreciate that the new experience is not tainted with the bad effects of my tiny typo. I fully 
agree with those who pointed out that last minute changes are a risky thing and I hope that this will not be necessary 
ever again. Otherwise I will remember the possible consequences well and ask experts to review and test. Ed, my offer is 
real ;-)


Cheers
/Eike


http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper




Everything else was identical, with one exception.

Where there were two versions of org.eclipse.rap.rwt_* in staging before, there 
is now only one:
org.eclipse.rap.rwt_2.1.0.20130611-2139.jar
and no longer the additional older version
org.eclipse.rap.rwt_2.1.0.20130527-1011.jar
If that was the RAP/Gyrex issue mentioned before, then it turns out you got your wish 
"for free" ... thanks to the
magical (not-completely-deterministic) behavior of p2, I guess.
(But, I'd be sure to test well :)

= = = =  = new CDO content:

staging/features: org.eclipse.emf.cdo.defs.source_4.2.0.v20130613-1556.jar
staging/features: org.eclipse.emf.cdo.defs_4.2.0.v20130613-1556.jar
staging/features: org.eclipse.emf.cdo.epp_4.2.0.v20130613-1556.jar
staging/features: org.eclipse.emf.cdo.sdk.source_4.2.0.v20130613-1556.jar
staging/features: org.eclipse.emf.cdo.sdk_4.2.0.v20130613-1556.jar
staging/features: org.eclipse.emf.cdo.source_4.2.0.v20130613-1556.jar
staging/features: org.eclipse.emf.cdo_4.2.0.v20130613-1556.jar
staging/plugins: org.eclipse.emf.cdo.net4j.source_4.1.100.v20130613-1556.jar
staging/plugins: org.eclipse.emf.cdo.net4j_4.1.100.v20130613-1556.jar
staging/plugins: org.eclipse.emf.cdo.net4j_4.1.100.v20130613-1556.jar.pack.gz

= = = = = =

Please let me know if that's not correct for CDOs new contribution.

Markus, I didn't quite follow my usual automated steps, so manually started a 
EPP repo build on Hudson once the new
staging repo was in place.

Thanks to Eike for his contributions and care for quality, and thanks to 
everyone who made constructive comments.





From: David M Williams/Raleigh/IBM@IBMUS
To: cross-project-issues-dev@eclipse.org,
Date: 06/12/2013 07:08 PM
Subject: [cross-project-issues-dev] Kepler's final staging repository is
complete
Sent by: cross-project-issues-dev-boun...@eclipse.org




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#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 adop

Re: [cross-project-issues-dev] Kepler's final re-staging repository is complete

[Markus Knauer]

Thank you, David, for taking care of the EPP repo build and starting it
manually.

Regarding the RAP issue with the duplicate bundles... Yes, we are lucky! I
kept my mouth shut in the discussion yesterday because I had the theory
that p2 would resolve this 'problem' itself by running the aggregator
again. ;-)
The only feature (org.eclipse.gyrex.features.dependencies.admin) that
defines a hard dependency to the bundle with the wrong version is not
contributed to the Kepler repository.

Thanks,
Markus



On Fri, Jun 14, 2013 at 4:31 AM, David M Williams  wrote:

> *http://download.eclipse.org/releases/staging/*
>
> After review from the Planning Council, I have respun the staging
> repository, with just the CDO contribution contributing anything new. For
> everyone else, I used the previous staging build as "input" for your
> contributions, so would expect identical contents (which, it turns out, is
> not quite the case).
>
> The new CDO files are as listed at the end of this note ... I hope that's
> what you were expecting ... more features changing than plugins!
>
> Everything else was identical, with one exception.
>
> Where there were two versions of org.eclipse.rap.rwt_* in staging before,
> there is now only one:
> org.eclipse.rap.rwt_2.1.0.20130611-2139.jar
> and no longer the additional older version
> org.eclipse.rap.rwt_2.1.0.20130527-1011.jar
> If that was the RAP/Gyrex issue mentioned before, then it turns out you
> got your wish "for free" ... thanks to the magical
> (not-completely-deterministic) behavior of p2, I guess.
> (But, I'd be sure to test well :)
>
> = = = =  = new CDO content:
>
> staging/features: org.eclipse.emf.cdo.defs.source_4.2.0.v20130613-1556.jar
> staging/features: org.eclipse.emf.cdo.defs_4.2.0.v20130613-1556.jar
> staging/features: org.eclipse.emf.cdo.epp_4.2.0.v20130613-1556.jar
> staging/features: org.eclipse.emf.cdo.sdk.source_4.2.0.v20130613-1556.jar
> staging/features: org.eclipse.emf.cdo.sdk_4.2.0.v20130613-1556.jar
> staging/features: org.eclipse.emf.cdo.source_4.2.0.v20130613-1556.jar
> staging/features: org.eclipse.emf.cdo_4.2.0.v20130613-1556.jar
> staging/plugins:
> org.eclipse.emf.cdo.net4j.source_4.1.100.v20130613-1556.jar
> staging/plugins: org.eclipse.emf.cdo.net4j_4.1.100.v20130613-1556.jar
> staging/plugins:
> org.eclipse.emf.cdo.net4j_4.1.100.v20130613-1556.jar.pack.gz
>
> = = = = = =
>
> Please let me know if that's not correct for CDOs new contribution.
>
> Markus, I didn't quite follow my usual automated steps, so manually
> started a EPP repo build on Hudson once the new staging repo was in place.
>
> Thanks to Eike for his contributions and care for quality, and thanks to
> everyone who made constructive comments.
>
>
>
>
>
> From:David M Williams/Raleigh/IBM@IBMUS
> To:cross-project-issues-dev@eclipse.org,
> Date:06/12/2013 07:08 PM
> Subject:[cross-project-issues-dev] Kepler's final staging
> repository iscomplete
> Sent by:cross-project-issues-dev-boun...@eclipse.org
> --
>
>
>
> 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#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 

Re: [cross-project-issues-dev] Kepler's final re-staging repository is complete

[David M Williams]

http://download.eclipse.org/releases/staging/ 

After review from the Planning Council, I have respun the staging 
repository, with just the CDO contribution contributing anything new. For 
everyone else, I used the previous staging build as "input" for your 
contributions, so would expect identical contents (which, it turns out, is 
not quite the case). 

The new CDO files are as listed at the end of this note ... I hope that's 
what you were expecting ... more features changing than plugins! 

Everything else was identical, with one exception. 

Where there were two versions of org.eclipse.rap.rwt_* in staging before, 
there is now only one:
org.eclipse.rap.rwt_2.1.0.20130611-2139.jar
and no longer the additional older version
org.eclipse.rap.rwt_2.1.0.20130527-1011.jar
If that was the RAP/Gyrex issue mentioned before, then it turns out you 
got your wish "for free" ... thanks to the magical 
(not-completely-deterministic) behavior of p2, I guess. 
(But, I'd be sure to test well :) 

= = = =  = new CDO content: 

staging/features: org.eclipse.emf.cdo.defs.source_4.2.0.v20130613-1556.jar
staging/features: org.eclipse.emf.cdo.defs_4.2.0.v20130613-1556.jar
staging/features: org.eclipse.emf.cdo.epp_4.2.0.v20130613-1556.jar
staging/features: org.eclipse.emf.cdo.sdk.source_4.2.0.v20130613-1556.jar
staging/features: org.eclipse.emf.cdo.sdk_4.2.0.v20130613-1556.jar
staging/features: org.eclipse.emf.cdo.source_4.2.0.v20130613-1556.jar
staging/features: org.eclipse.emf.cdo_4.2.0.v20130613-1556.jar
staging/plugins: 
org.eclipse.emf.cdo.net4j.source_4.1.100.v20130613-1556.jar
staging/plugins: org.eclipse.emf.cdo.net4j_4.1.100.v20130613-1556.jar
staging/plugins: 
org.eclipse.emf.cdo.net4j_4.1.100.v20130613-1556.jar.pack.gz

= = = = = = 

Please let me know if that's not correct for CDOs new contribution. 

Markus, I didn't quite follow my usual automated steps, so manually 
started a EPP repo build on Hudson once the new staging repo was in place. 


Thanks to Eike for his contributions and care for quality, and thanks to 
everyone who made constructive comments. 





From:   David M Williams/Raleigh/IBM@IBMUS
To: cross-project-issues-dev@eclipse.org, 
Date:   06/12/2013 07:08 PM
Subject:[cross-project-issues-dev] Kepler's final staging 
repository is   complete
Sent by:cross-project-issues-dev-boun...@eclipse.org



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#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 

Thanks everyone. Good luck with your final testing and wrap-up. 
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

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

Re: [cross-project-issues-dev] Kepler's final staging repository is complete

[Wayne Beaton]

  
  
The Technology PMC is lead by Gunnar. But Chris and I can take the
initiative.

I would not ask for a respin to address the m2e-wtp "problem". IMHO,
the errant feature conforms to the spirit of the rules and so does
not warrant a respin in and of itself.

I would not, however, say no if there is an opportunity to slip the
corrected feature JAR in.

Is that vague and non-committal enough?

Wayne

On 06/13/2013 02:42 PM, David M
  Williams wrote:

So, now we have two
requests. 
  
  
  And, luckily for you all, I am
not the
(final) decision maker here ... for me, it has to be a "causes
the
machine to burst into flames" sort of problem to justify a
respin
:) 
  
  
  But, there is a Planning Council
Exception
process and I'm quite happy to listen to the judgement of other
planning
council members if the risks are worth the benefits.  
  
  
  So, I'd like the Planning Council
rep
for these two projects to send "exception requests notes" to
Planning Council list (if they agree a respin is required) and
solicit
the necessary support from other PC members. 
  
  
  I know most of you hate process
...
but ... this is one reason why we have it ... so things just
don't come
down to my judgement. 
  
  
  I've sent an email to Ed (CDOs
rep)
asking him his opinion and if he agrees to send note to Planning
Council
list and by this note, ask the m2e-wtp
representatives to do the same (you are in Technology project,
right? ...
so that'd be Wayne or Chris). 
  
  
  I don't mean to belittle either
issue
(or, "be hard" on anyone personally) ... but ... as a release
engineer, I am too aware of the many things that can go wrong
with a last
minute respin and the risks of making things worse. 
  
  
  Thanks for your patience, 
  
  
  
  
  
  
  From:      
 Fred Bricon

  
  To:      
 Cross project issues
, 
  
  Date:      
 06/13/2013 02:20 PM
  
  Subject:    
   Re:
[cross-project-issues-dev]
Kepler's final staging repository is        complete
  
  Sent by:    
   cross-project-issues-dev-boun...@eclipse.org
  
  
  
  
  
  +1 for a respin. That'd -hopefully- allow the build
to
pick up a now conform (epl-v10.html/signed) mavenarchiver
feature for m2e-wtp. https://bugs.eclipse.org/bugs/show_bug.cgi?id=410670
  
  
  Fred Bricon
  
  
  
  
  2013/6/13 Eike Stepper 
  
  Am 13.06.2013 20:01, schrieb Ed Willink:
  
  
  Hi

CDO is too important a project to not fix this, so I vote for
the (partial)
respin.
  
  
  Thanks!
  
  
  
  
  Maybe next year we can have a bit more reviewing,
approving
and testing.
  
  
  I invite you to work on CDO internals and become a
committer,
so that you can review us next year :P
  
  

Cheers
/Eike


http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

  
  
  ___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
  
  
  
  
  
  -- 
"Have you tried turning it off and on again" - The IT Crowd ___
  cross-project-issues-dev mailing list
  cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

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



-- 
  Wayne Beaton
  Director of Open Source Projects, The Eclipse Foundation
  Learn about Eclipse
Projects
  
  

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

Re: [cross-project-issues-dev] Kepler's final staging repository is complete

[Denis Roy]

On 06/13/2013 03:46 PM, John Arthorne wrote:

> From: Denis Roy 
>
> On which day does "last minute" begin, as we are 13 days away from
> the release?  As a casual observer I'm puzzled by the "test early,
> test often, fix nothing" mantra.  Does today's RC somehow become
> null and void if a respin is made and serious problems arise from it?

CDO is a +2 project, so their RC4 deadline was Tuesday. So this is two 
days after their deadline, which is definitely "last minute". My 
impression is that the bug is serious and we should fix it in this 
case, but I think it was quite reasonable for David to request that we 
follow the process to make sure that all projects are informed and 
have an opportunity to give their input.


This particular case was a perfect example of why we need to be 
cautious and have a process for fixing even serious problems at this 
stage. In this situation a fix for a "serious" problem two days ago 
introduced a much worse regression that has now become a blocker. This 
is no reflection on CDO - every project I have worked on has had cases 
like this where a heavily reviewed and tested last minute fix has 
introduced a bug more serious than the one we were attempting to fix. 
Sometimes shipping a known bug is better than risking introducing a 
worse bug. As I said in this case I gave my +1 but sometimes "fix 
nothing" is the right answer.


I naively thought we could spin a RC4a candidate, test it and use it if 
it's better, discard it and use current RC4 if it's not.


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

Re: [cross-project-issues-dev] Kepler's final staging repository is complete

[David M Williams]

Ralf, my current plan is to do the respin using the last aggregation build 
as "input", except for those cases approved by Planning Council ... so, 
would ask for you to do the same. Work the issue through your PMC and 
Planning Council rep first (Ian Bull) and if they all agree, to Ian to 
submit exception request note to planning council list. 

Thanks, 




From:   Ralf Sternberg 
To: Cross project issues , 
Date:   06/13/2013 03:55 PM
Subject:Re: [cross-project-issues-dev] Kepler's final staging 
repository is   complete
Sent by:cross-project-issues-dev-boun...@eclipse.org



I'm hesitating to bring it up, but ... in case a respin is done, it
would be good if this build could eliminate the outdated rap.rwt
bundle that was accidentally contributed by Gyrex [1]. This version of
the rap.rwt bundle contains a critical bug [2] that is fixed in RAP's
final RC4 contribution.

This bug causes IE browsers to fire requests permanently for certain
RAP applications and put the server under extreme load. Even though
RAP is not affected by this duplicate (AFAIK), I would feel better if
this bundle was not in the Kepler repository. I'm sorry that this bug
made it even into RC3, this problem is almost invisible at development
time and could not be discovered by any of our unit tests, browser
tests or integration tests.

Regards,
Ralf

[1] Bug 409457: Contributing old RAP 2.1 bundles to Kepler
https://bugs.eclipse.org/bugs/show_bug.cgi?id=409457

[2] Bug 410157: [ServerPush] ServerPush requests always return immediately 
in IE
https://bugs.eclipse.org/bugs/show_bug.cgi?id=410157
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


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

Re: [cross-project-issues-dev] Kepler's final staging repository is complete

[Ralf Sternberg]

I'm hesitating to bring it up, but ... in case a respin is done, it
would be good if this build could eliminate the outdated rap.rwt
bundle that was accidentally contributed by Gyrex [1]. This version of
the rap.rwt bundle contains a critical bug [2] that is fixed in RAP's
final RC4 contribution.

This bug causes IE browsers to fire requests permanently for certain
RAP applications and put the server under extreme load. Even though
RAP is not affected by this duplicate (AFAIK), I would feel better if
this bundle was not in the Kepler repository. I'm sorry that this bug
made it even into RC3, this problem is almost invisible at development
time and could not be discovered by any of our unit tests, browser
tests or integration tests.

Regards,
Ralf

[1] Bug 409457: Contributing old RAP 2.1 bundles to Kepler
https://bugs.eclipse.org/bugs/show_bug.cgi?id=409457

[2] Bug 410157: [ServerPush] ServerPush requests always return immediately in IE
https://bugs.eclipse.org/bugs/show_bug.cgi?id=410157
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Kepler's final staging repository is complete

[John Arthorne]

> From: Denis Roy 
> 
> On which day does "last minute" begin, as we are 13 days away from 
> the release?  As a casual observer I'm puzzled by the "test early, 
> test often, fix nothing" mantra.  Does today's RC somehow become 
> null and void if a respin is made and serious problems arise from it?

CDO is a +2 project, so their RC4 deadline was Tuesday. So this is two 
days after their deadline, which is definitely "last minute". My 
impression is that the bug is serious and we should fix it in this case, 
but I think it was quite reasonable for David to request that we follow 
the process to make sure that all projects are informed and have an 
opportunity to give their input. 

This particular case was a perfect example of why we need to be cautious 
and have a process for fixing even serious problems at this stage. In this 
situation a fix for a "serious" problem two days ago introduced a much 
worse regression that has now become a blocker. This is no reflection on 
CDO - every project I have worked on has had cases like this where a 
heavily reviewed and tested last minute fix has introduced a bug more 
serious than the one we were attempting to fix. Sometimes shipping a known 
bug is better than risking introducing a worse bug. As I said in this case 
I gave my +1 but sometimes "fix nothing" is the right answer.

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

Re: [cross-project-issues-dev] Fwd: Re: Kepler's final staging repository is complete

[Steffen Pingel]

+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  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 +  From: Pascal Rapicault
>Reply-To:
> Cross project issues 
>   
> To:
> Cross project issues 
> 
>
> 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-boun...@eclipse.org 
> [mailto:cross-project-issues-dev-boun...@eclipse.org 
> ] On Behalf Of Eike Stepper
> Sent: June-13-13 1:42 PM
> To: cross-project-issues-dev@eclipse.org
> 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.dehttp://thegordian.blogspot.comhttp://twitter.com/eikestepper
>
>
>
> >
> > Thanks for bringing it to our attention, in either case.
> >
> >
> >
> >
> > From: Eike Stepper  
> > To: cross-project-issues-dev@eclipse.org,
> > Date: 06/13/2013 12:10 PM
> > Subject: Re: [cross-project-issues-dev] Kepler's final staging repository 
> > iscomplete
> > Sent by: cross-project-issues-dev-boun...@eclipse.org
> > --
> > --
> >
> >
> >
> > 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, 1L);
> >  }
> >
> > That not only does

Re: [cross-project-issues-dev] Fwd: Re: Kepler's final staging repository is complete

[Daniel Megert]

+1

Dani


From:
Ed Merks 
To:
eclipse.org-planning-coun...@eclipse.org, 
Cc:
Cross project issues 
Date:
13.06.2013 21:07
Subject:
[cross-project-issues-dev] Fwd: Re: Kepler's final staging repository is 
complete



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 +
From: 
Pascal Rapicault 
Reply-To: 
Cross project issues 
To: 
Cross project issues 


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-boun...@eclipse.org [
mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Eike 
Stepper
Sent: June-13-13 1:42 PM
To: cross-project-issues-dev@eclipse.org
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 
> To: cross-project-issues-dev@eclipse.org,
> Date: 06/13/2013 12:10 PM
> Subject: Re: [cross-project-issues-dev] Kepler's final staging 
repository iscomplete
> Sent by: cross-project-issues-dev-boun...@eclipse.org
> --
> --
>
>
>
> 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, 1L);
>  }
>
> 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://thegordian.blogspot.c

Re: [cross-project-issues-dev] Kepler's final staging repository is complete

[Doug Schaefer]

What Denis said. +1

From: Denis Roy mailto:denis@eclipse.org>>
Reply-To: Cross project issues 
mailto:cross-project-issues-dev@eclipse.org>>
Date: Thursday, 13 June, 2013 3:16 PM
To: 
"cross-project-issues-dev@eclipse.org"
 
mailto:cross-project-issues-dev@eclipse.org>>
Subject: Re: [cross-project-issues-dev] Kepler's final staging repository is 
complete


I don't mean to belittle either issue (or, "be hard" on anyone personally) ... 
but ... as a release engineer, I am too aware of the many things that can go 
wrong with a last minute respin and the risks of making things worse.

On which day does "last minute" begin, as we are 13 days away from the release? 
 As a casual observer I'm puzzled by the "test early, test often, fix nothing" 
mantra.  Does today's RC somehow become null and void if a respin is made and 
serious problems arise from it?
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Kepler's final staging repository is complete

[Denis Roy]

I don't mean to belittle either issue (or, "be hard" on anyone 
personally) ... but ... as a release engineer, I am too aware of the 
many things that can go wrong with *a last minute respin* and the 
risks of *making things worse*.


On which day does "last minute" begin, as we are 13 days away from the 
release?  As a casual observer I'm puzzled by the "test early, test 
often, fix nothing" mantra.  Does today's RC somehow become null and 
void if a respin is made and serious problems arise from it?
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] Fwd: Re: Kepler's final staging repository is complete

[Ed Merks]

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 +
From:   Pascal Rapicault 
Reply-To:   Cross project issues 
To: Cross project issues 



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-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Eike Stepper
Sent: June-13-13 1:42 PM
To: cross-project-issues-dev@eclipse.org
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 
To: cross-project-issues-dev@eclipse.org,
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-boun...@eclipse.org
--
--



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, 1L);
 }

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://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 th

Re: [cross-project-issues-dev] Kepler's final staging repository is complete

[David M Williams]

So, now we have two requests. 

And, luckily for you all, I am not the (final) decision maker here ... for 
me, it has to be a "causes the machine to burst into flames" sort of 
problem to justify a respin :) 

But, there is a Planning Council Exception process and I'm quite happy to 
listen to the judgement of other planning council members if the risks are 
worth the benefits. 

So, I'd like the Planning Council rep for these two projects to send 
"exception requests notes" to Planning Council list (if they agree a 
respin is required) and solicit the necessary support from other PC 
members. 

I know most of you hate process ... but ... this is one reason why we have 
it ... so things just don't come down to my judgement. 

I've sent an email to Ed (CDOs rep) asking him his opinion and if he 
agrees to send note to Planning Council list and by this note, ask the 
m2e-wtp representatives to do the same (you are in Technology project, 
right? ... so that'd be Wayne or Chris). 

I don't mean to belittle either issue (or, "be hard" on anyone personally) 
... but ... as a release engineer, I am too aware of the many things that 
can go wrong with a last minute respin and the risks of making things 
worse. 

Thanks for your patience, 





From:   Fred Bricon 
To: Cross project issues , 
Date:   06/13/2013 02:20 PM
Subject:Re: [cross-project-issues-dev] Kepler's final staging 
repository is   complete
Sent by:cross-project-issues-dev-boun...@eclipse.org



+1 for a respin. That'd -hopefully- allow the build to pick up a now 
conform (epl-v10.html/signed) mavenarchiver feature for m2e-wtp. 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=410670

Fred Bricon


2013/6/13 Eike Stepper 
Am 13.06.2013 20:01, schrieb Ed Willink:

Hi

CDO is too important a project to not fix this, so I vote for the 
(partial) respin.

Thanks!


Maybe next year we can have a bit more reviewing, approving and testing.

I invite you to work on CDO internals and become a committer, so that you 
can review us next year :P


Cheers
/Eike


http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper


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



-- 
"Have you tried turning it off and on again" - The IT Crowd 
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

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

Re: [cross-project-issues-dev] Kepler's final staging repository is complete

[Miles Parker]

Yeah, I was just thinking … "hmmm.. maybe we could squeeze a couple more 
Reviews fixes in there as well… bwahahahaha!"

-Miles

On 2013-06-13, at 11:35 AM, Fred Bricon  wrote:

> I know it's benign, that's why I didn't request a respin in the first place. 
> Now it doesn't hurt to ask :-)
> 
> 
> 2013/6/13 Pascal Rapicault 
> And so started the respin where everything changed…
> 
>  
> 
> Fred, this is far from being a blocker change, so even though this is a 
> benign change, I don’t know if we want to consume it.
> 
>  
> 
> From: cross-project-issues-dev-boun...@eclipse.org 
> [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Fred Bricon
> Sent: June-13-13 2:16 PM
> To: Cross project issues
> 
> 
> Subject: Re: [cross-project-issues-dev] Kepler's final staging repository is 
> complete
> 
>  
> 
> +1 for a respin. That'd -hopefully- allow the build to pick up a now conform 
> (epl-v10.html/signed) mavenarchiver feature for m2e-wtp. 
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=410670
> 
>  
> 
> Fred Bricon
> 
>  
> 
> 2013/6/13 Eike Stepper 
> 
> Am 13.06.2013 20:01, schrieb Ed Willink:
> 
>  
> 
> Hi
> 
> CDO is too important a project to not fix this, so I vote for the (partial) 
> respin.
> 
>  
> 
> Thanks!
> 
>  
> 
> Maybe next year we can have a bit more reviewing, approving and testing.
> 
>  
> 
> I invite you to work on CDO internals and become a committer, so that you can 
> review us next year :P
> 
> 
> 
> Cheers
> /Eike
> 
> 
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
> 
> 
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
> 
> 
> 
> 
>  
> 
> -- 
> "Have you tried turning it off and on again" - The IT Crowd
> 
> 
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
> 
> 
> 
> 
> -- 
> "Have you tried turning it off and on again" - The IT Crowd
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

__
Miles T. Parker, M.Sc.
Tasktop Labs
http://tasktop.com
Lead: Eclipse Mylyn MFT, AMP
Committer: Eclipse Mylyn Reviews, R4E, Virgo
http://milesparker.blogspot.com




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

Re: [cross-project-issues-dev] Kepler's final staging repository is complete

[Fred Bricon]

I know it's benign, that's why I didn't request a respin in the first
place.
Now it doesn't hurt to ask :-)


2013/6/13 Pascal Rapicault 

>  And so started the respin where everything changed…
>
> ** **
>
> Fred, this is far from being a blocker change, so even though this is a
> benign change, I don’t know if we want to consume it.
>
> ** **
>
> *From:* cross-project-issues-dev-boun...@eclipse.org [mailto:
> cross-project-issues-dev-boun...@eclipse.org] *On Behalf Of *Fred Bricon
> *Sent:* June-13-13 2:16 PM
> *To:* Cross project issues
>
> *Subject:* Re: [cross-project-issues-dev] Kepler's final staging
> repository is complete
>
> ** **
>
> +1 for a respin. That'd -hopefully- allow the build to pick up a now
> conform (epl-v10.html/signed) mavenarchiver feature for m2e-wtp.
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=410670
>
> ** **
>
> Fred Bricon
>
> ** **
>
> 2013/6/13 Eike Stepper 
>
> Am 13.06.2013 20:01, schrieb Ed Willink:
>
> ** **
>
> Hi
>
> CDO is too important a project to not fix this, so I vote for the
> (partial) respin.
>
> ** **
>
> Thanks!
>
> ** **
>
> Maybe next year we can have a bit more reviewing, approving and testing.**
> **
>
> ** **
>
> I invite you to work on CDO internals and become a committer, so that you
> can review us next year :P
>
>
>
> Cheers
> /Eike
>
> 
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
> 
>
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
>
>
> 
>
> ** **
>
> --
> "Have you tried turning it off and on again" - The IT Crowd 
>
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
>


-- 
"Have you tried turning it off and on again" - The IT Crowd
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Kepler's final staging repository is complete

[Pascal Rapicault]

And so started the respin where everything changed…

Fred, this is far from being a blocker change, so even though this is a benign 
change, I don’t know if we want to consume it.

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Fred Bricon
Sent: June-13-13 2:16 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Kepler's final staging repository is 
complete

+1 for a respin. That'd -hopefully- allow the build to pick up a now conform 
(epl-v10.html/signed) mavenarchiver feature for m2e-wtp. 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=410670

Fred Bricon

2013/6/13 Eike Stepper mailto:step...@esc-net.de>>
Am 13.06.2013 20:01, schrieb Ed Willink:

Hi

CDO is too important a project to not fix this, so I vote for the (partial) 
respin.

Thanks!

Maybe next year we can have a bit more reviewing, approving and testing.

I invite you to work on CDO internals and become a committer, so that you can 
review us next year :P


Cheers
/Eike


http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

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



--
"Have you tried turning it off and on again" - The IT Crowd
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Kepler's final staging repository is complete

[Fred Bricon]

+1 for a respin. That'd -hopefully- allow the build to pick up a now
conform (epl-v10.html/signed) mavenarchiver feature for m2e-wtp.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=410670

Fred Bricon


2013/6/13 Eike Stepper 

> Am 13.06.2013 20:01, schrieb Ed Willink:
>
>  Hi
>>
>> CDO is too important a project to not fix this, so I vote for the
>> (partial) respin.
>>
>
> Thanks!
>
>
>  Maybe next year we can have a bit more reviewing, approving and testing.
>>
>
> I invite you to work on CDO internals and become a committer, so that you
> can review us next year :P
>
>
> Cheers
> /Eike
>
> 
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
> __**_
> cross-project-issues-dev mailing list
> cross-project-issues-dev@**eclipse.org
> https://dev.eclipse.org/**mailman/listinfo/cross-**project-issues-dev
>



-- 
"Have you tried turning it off and on again" - The IT Crowd
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Kepler's final staging repository is complete

[Eike Stepper]

No matter how this will be decided, I've updated our contribution file with a new, good R-build. It's next to impossible 
that we srew the aggregation up with it.


Thanks and sorry again for all the hazzle!

Cheers
/Eike


http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper



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

Re: [cross-project-issues-dev] Kepler's final staging repository is complete

[Eike Stepper]

Am 13.06.2013 20:01, schrieb Ed Willink:

Hi

CDO is too important a project to not fix this, so I vote for the (partial) 
respin.


Thanks!


Maybe next year we can have a bit more reviewing, approving and testing.


I invite you to work on CDO internals and become a committer, so that you can 
review us next year :P

Cheers
/Eike


http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper


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

Re: [cross-project-issues-dev] Kepler's final staging repository is complete

[Mickael Istria]

On 06/13/2013 07:46 PM, Pascal Rapicault wrote:

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?
Although I may miss some potential issues about release train build, I'd 
like to vote +1 as it's a minor change that doesn't impact API. Only CDO 
would need to re-build and be allowed to change its contribution to 
Kepler. When done, it seems to me that it's just a matter of running a 
new aggregation.
It doesn't seem risky to make such a change as we're still far enough 
from release.

--
Mickael Istria
Eclipse developer at JBoss, by Red Hat 
My blog  - My Tweets 

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

Re: [cross-project-issues-dev] Kepler's final staging repository is complete

[Ed Willink]

Hi

CDO is too important a project to not fix this, so I vote for the 
(partial) respin.


Maybe next year we can have a bit more reviewing, approving and testing.

Regards

Ed Willink


On 13/06/2013 18:46, Pascal Rapicault wrote:

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-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Eike Stepper
Sent: June-13-13 1:42 PM
To: cross-project-issues-dev@eclipse.org
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
To: cross-project-issues-dev@eclipse.org,
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-boun...@eclipse.org
--
--



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, 1L);
  }

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://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 req

Re: [cross-project-issues-dev] Kepler's final staging repository is complete

[Markus Knauer]

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  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 
>> To: 
>> cross-project-issues-dev@**eclipse.org
>> ,
>> Date: 06/13/2013 12:10 PM
>> Subject: Re: [cross-project-issues-dev] Kepler's final staging repository
>> iscomplete
>> Sent by: 
>> cross-project-issues-dev-**boun...@eclipse.org
>> --**--**
>> --**--
>>
>>
>>
>>
>> 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, 1L);
>>  }
>>
>> 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://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 wit

Re: [cross-project-issues-dev] Kepler's final staging repository is complete

[Pascal Rapicault]

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-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Eike Stepper
Sent: June-13-13 1:42 PM
To: cross-project-issues-dev@eclipse.org
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 
> To: cross-project-issues-dev@eclipse.org,
> 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-boun...@eclipse.org
> --
> --
>
>
>
> 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, 1L);
>  }
>
> 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://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 

Re: [cross-project-issues-dev] Kepler's final staging repository is complete

[Eike Stepper]

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 
To: cross-project-issues-dev@eclipse.org,
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-boun...@eclipse.org




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, 1L);
 }

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://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#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 

Re: [cross-project-issues-dev] Kepler's final staging repository is complete

[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? 

Does this impact any/many EPP packages? If so, which ones, and what are 
"effects". How many users (use-cases) would be effected? 

>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. 

Thanks for bringing it to our attention, in either case. 




From:   Eike Stepper 
To: cross-project-issues-dev@eclipse.org, 
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-boun...@eclipse.org



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, 1L);
 }

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://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#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
>
> Thanks everyone. Good luck with your final testing and wrap-up.
>
>
>
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>

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


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

Re: [cross-project-issues-dev] Kepler's final staging repository is complete

[Eike Stepper]

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, 1L);
}

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://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#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

Thanks everyone. Good luck with your final testing and wrap-up.



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



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