[cbi-dev] Summary for conf call for having native parts builds moved to

[Aleksandar Kurtakov <akurtako@xxxxxxxxxx>]

Eclipse.org infra is heading towards providing infra for rebuilding the native parts of Eclipse platform for Win, Mac, Linux x86_64 (x86?). There are more parts that contain native code but the two crucial parts are SWT and Equinox Launcher so work starting on them. For simplicity the first ws/os/arch combo to be worked on will gtk.linux.x86_64.
Current native build scripts are monolithic in terms of one platform failing to builds leads to none recieving rebuilt native library. New approach will be that whatever platform succeeds in rebuild is committed and the rest will be let to fail during the aggregation or tests run. Natives not done @eclipse.org (rest of ws/os/arch combos produced currently) will be contributed by member companies and it will be their duty to sync up builds. N-builds and I-builds might have some different requirements for synchronization. 
A proposal for contributing a remote machine maintained at member company but being attached as Hudson slave for doing the build for additional platforms was done by Mikael not much interest in it now (Mikael, please ellaborate).
Build will be done in Hudson with one job per platform, build with Maven - `mvn clean verify -Dnative=ws.os.arch` to open the door for simplifying the build script and hudson will commit to the git repo (noone objected). What about version bumps/tags/etc.? Don't remember being discussed. 

Initial work plan is:
1. Duplicate platform repos in cbi for swt.binaries, equinox.binaries and releng.aggregator (to make submodules point to cbi swt.binaries, equinox.binaries repos).
2. Get slaves for build machines - RHEL being a blocker for the initial work, Mac/Win to open paralel fronts 
3. Have builds running on this slaves - Most things available now, only big missing thing is Xulrunner AFAIK.
4. Get hudson committing to the cbi git repos on successful builds
5. Run aggregation job - it would produce all the tarballs/zips but only the one targetted will be expected.
6. Find some comparator tool and run it against zip produced by this new build and the old way produced one to find potential differences.

Additional points from the talk:
* It would be nice to decouple platforms as maven profiles so only one of given subset can be built (David) - It would not be build scripts work only but it would require work on PDE side to allow it as fragments are included in features and they have to be resolved even if the platform is not going to be build in this run. Can be tackled as separate project if people interested in it.
* PDE is using hardcoded arch list - would be nice to have it dynamic in some way based on contributed archs

Let's have initial read and corrections and I'll start filing bz to get tracking for all the tasks.

Please correct, extend, add for whatever I missed or misunderstood,
Alexander Kurtakov
Red Hat Eclipse team