I am a big supporter of more rigorous approach to simrel aggregation, but what do we hope to gain from using Gerrit when the majority of projects contribute a fixed URL that they vary the content of as need be?
- Konstantin
From: cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of David M Williams
Sent: Thursday, March 26, 2015 1:06 PM
To: cross-project-issues-dev@xxxxxxxxxxx
Subject: [cross-project-issues-dev] Changes in Sim. Release Mechanics starting Monday 3/30: Gerrit, HIPP Instance, and Java 7
Once M6 is out the door, we have some changes planned for some of the "mechanics" involving the Sim. Release Repository.
-- Gerrit use allowed (required).
This is the largest change discussed in this note, since this requires everyone to change the URL you use to "push" to the Git repository that contains the b3aggrcon files.
Note that "Gerrit review" is not required and at this time there will be no "mandatory build/test passing" (but, could be in future, probably post-Mars release). So for now, you can still push your changes directly to the repository, but will have to be done using the Gerrit URL.
The instructions "Contributing to Simrel Aggregation Build" [1] have been updated with the new procedure. Please do not wait until "the last minute" to update your settings and access, but give it a try next week! It is expected that the webmasters will make the change "Monday Morning" (Eastern Time) so the "new URL" should work Monday afternoon (and the old one no longer work). If you have not used Gerrit at Eclipse before, there is some "prep work" you need to do, to have access (SSH keys, and similar).
See bug 422215 [2] for the discussion of this change to use Gerrit.
-- Build to move to HIPP Instance.
The aggregation build will now take place on it's own "HIPP Instance". For the most part, this won't effect your "mechanics" any, but it may change the "notification" you get, because we will do the build in three steps. VALIDATE, BUILD (with cached contents), 3) CLEAN BUILD. It is the "clean build" that is just like the previous "shared instance" job -- and that is still the final goal -- but in many cases, the feedback about your contribution will "come back" to you sooner, if there are problems. I hope to soon update all URLs (in FAQs, etc.) to point to "the right" location, but in the mean time, that build machine can be found from the "general HIPP page" [3] (it is named "Simrel"), or you can bookmark the direct URL [4]. If you need to "start a build" all committers to Sim. Release can start a "VALIDATE" build. From there, the others are started automatically upon success of previous step. At least for now, if not forever, we will still publish the results from the clean build to "staging" and "maintenance" on download server, as we have before.
See bug 462859 [5] for discussion of this transition to the HIPP Instance.
-- Java 7 will be used to run the build, including unpacking the "*.jar.pack.gz" files. We have been using Java 6 "unpack200". From some early testing, I've seen no difference in what unpacks cleanly, and what does not, but in theory, there could be. (In particular, if you have "nested, packed gz jars, Java 7 is known not to have issues with that, but, few people do have nested packed jars, any longer, and for the one case I know about (Window Builder) it doesn't seem to make any difference in what the aggregator does (though, might still, at run-time .... every one is encourage to no longer use nested packed jars. (You can still have nested jars, and the overall bundle can still be packed, this is just about the "inner" (or, "child" jars) that should not be "packed").
See bug 463010 [6] for more details about this switch, if interested.
As always, questions and comments are welcome.
Thanks,
[1] https://wiki.eclipse.org/Simrel/Contributing_to_Simrel_Aggregation_Build
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=422215
[3] https://hudson.eclipse.org/
[4] https://hudson.eclipse.org/simrel/
[5] https://bugs.eclipse.org/bugs/show_bug.cgi?id=462859
[6] https://bugs.eclipse.org/bugs/show_bug.cgi?id=463010
