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 <david_willi...@us.ibm.com > wrote: > *http://download.eclipse.org/releases/staging/*<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/*<http://download.eclipse.org/releases/staging/> > > The final repo-reports are available at the usual place: > * > **http://build.eclipse.org/simrel/kepler/reporeports/*<http://build.eclipse.org/simrel/kepler/reporeports/> > > For those of you with "missing legal files" ... it is between you and the > EMO if they will grant an exception for the release. > I know of only one project that as requested it (bug 401273). > > As for other things, such as unsigned jars, technically you should work > with your PMC and planning representative to ask for exceptions, > but suspect if you have not done so by now, it's simply a matter that you > don't care. But, if you do, the reference is * > ** > http://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements#Planning_Council_Exception_Process > *<http://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements#Planning_Council_Exception_Process> > Beyond that, I'll leave it up to the rest of the Planning Council to raise > objections if they think any violations are so egregious it deserves > discussing whether or not to included in the common repo. > > Remember that as we enter "quiet week" we do NOT promote the builds to > their usual place, since to do so is basically making the release > available early. > The purpose of "quiet week" is partially to allow adopters to do final > acceptance testing, but to also serve as a buffer in case a build is > required -- but, rebuilds are very risky, and rare, so has to be an > especially bad bug (such as one which prevents install or update from > working, or perhaps where one project prevents another project from > working). > Otherwise, the extra time is for projects to prepare "hot fix" feature > patches to be available from their own project repositories. > > If you like to read wordy, but possibly educational, documents, don't > forget about * > **http://wiki.eclipse.org/Kepler/Final_Daze*<http://wiki.eclipse.org/Kepler/Final_Daze> > > Thanks everyone. Good luck with your final testing and wrap-up. > _______________________________________________ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.org > 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
