Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Kepler's final re-staging repository is complete

Am 14.06.2013 04:31, schrieb David M Williams:

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:

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 ;-)



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:
and no longer the additional older version
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@xxxxxxxxxxx,
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-bounces@xxxxxxxxxxx

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.

The final repo-reports are available at the usual place:

For those of you with "missing legal files" ... it is between you and the EMO if they will grant an exception for the
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 _
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

If you like to read wordy, but possibly educational, documents, don't forget about_

Thanks everyone. Good luck with your final testing and wrap-up.
cross-project-issues-dev mailing list

cross-project-issues-dev mailing list

Back to the top