I'm sure no one needs a reminder, that today is the final day to contribute to the Mars.1 update release.
Unless there are blocking problems ... which is relatively rare. 1. = = = = = finishing up Besides the usual "legal files" report I always point to: https://hudson.eclipse.org/simrel/job/simrel.mars.runaggregator.BUILD__CLEAN/lastSuccessfulBuild/artifact/aggregation/final/buildInfo/reporeports/reports/layoutCheck.txt (for which, there's been no recent progress ... except for Buildship, Thank you Buildship!) I also spent some time looking at the "multiple versions" report: https://hudson.eclipse.org/simrel/job/simrel.mars.runaggregator.BUILD__CLEAN/lastSuccessfulBuild/artifact/aggregation/final/buildInfo/reporeports/reports/nonUniqueVersions.txt I know sometimes multiple versions are needed, and are fine ... but, I see some that are either "just wrong", or *might* cause issues? I've opened the following bug with those that seem odd, to me, and would appreciate "those in the know" taking a quick peek to see if any are harmful -- at least those in the bug, if not the whole report. Bug 477614 - Unusual "mult version" bundles in Mars.1 (near) release 2. = = = = = what's next? The official release date is 9/25 (even though "code and packages" should be done by 9/18. To repeat, or explain to new comers, we always have a "quiet week" after code is ready, primarily to allow "buffer" in case an emergency rebuild is required and to allow adopters to do their final builds and testing, if they desire. But, there are a number of other things to do during this "quiet week". a. Update any docs you may have in the info center. I've opened a new bug for Mars.1 (477616 ) b. Continue to test and work with adopters to make sure they are testing! (if you can) Even if a "bad problem" is not bad enough to rebuild the whole train, it is often useful to know about those issues before the release, so that "work-arounds" can be documented, or, in some cases, updates from your own project sites supplied. c. Archive any "old releases" so as to not stress our mirroring system. d. Publish artifacts "where they belong" but do no make them visible yet to the general public on "downloads" pages or "p2 software sites". You can begin doing this as early as the weekend, or on Monday, if you can. This allows time them to "mirror" before there is a large demand for them and avoids bottlenecks in the Eclipse.org infrastructure. And, you may have other things ... polish/update websites, etc., But those are the basics. If any questions, some of them may be answered in https://wiki.eclipse.org/Mars/Final_Daze but don't hesitate to ask, here on this list. Coming soon .. Neon M2! Seriously, thanks for everyone's participation and help in getting this update release out.
_______________________________________________ cross-project-issues-dev mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
