Orbit Minutes 070724
- Call convened at 1000 EDT
- Client call setup: [Asterisk Conference Calls]
- Conf id: 8978
- PIN: 82713
- Back-up Call-in: 613.287.8000 or 866.362.7064, passcode 892048#
- Previous Meeting: Orbit Minutes 070626
We have also added a basic test suite which verifies the layout of bundles.
- some tests are currently fail because their manifest files aren't the right casing
- people need to change manifest casing
- Action: DJ to enter bug against PDE to validate the casing. (Done - bug 194650)
- Action: DJ to gather bundles which are failing and will send note to mailing list.
- We need to see if these are tested on Linux.
Now that we have declared a "recommended" build, is it ok to start releasing new bundles to Orbit?
- remove for this week
- add nightly builds? requires separate streams
- R-builds are really a packaging problem?
- build it from a status file?
- Action: Chris to remove 2 new bundles from feature/map file until next week. (Done)
The Eclipse Foundation has a new infrastructure for conference calls. We should start using it for Orbit calls.
- Action: Jeff to co-ordinate and send note with new info.
Do we want to try and make the GET URLs generated by Orbit be build-independent? That is, not have the build id in it so consumers don't always have to update their map files if there is a new Orbit build and their bundle didn't change?
- Action: DJ to write wiki describing problems.
There are some problems with signed bundles because not all teams sign. (and Orbit doesn't)
- e.g. platform signs but wtp doesn't sign - same bundle, same qualifier
- signing is not a requirement for Europa
- orbit doesn't sign but always said we should
- probably a couple days or a weeks worth of work to modify build scripts
- Action: David to send a note to cross-project warning people of potential problems. (Done)
- only happens when you have people unzipping on top of a signed version
Discussions surrounding Orbit R-Builds.
- when is the next r-build?
- how do we plan for this?
- same as regular project?
- branch releng project to europa_maintenance
- need to tag the map files for each build
- do we really need branches?
- create new map files? had because its based on what people consume
- how about new features? set1 is for europa, something new for maintenance, etc.
- thought from Pascal: have the build produce multiple map files, one for each consumer based on the info in the ip log file
July 24, 2007 at 1000 EDT, Agenda: Orbit Minutes 070724