Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Orbit Minutes 070724"
(→Bundle downloads) |
|||
| Line 1: | Line 1: | ||
* Call convened at [http://timeanddate.com/worldclock/fixedtime.html?month=07&day=24&year=2007&hour=10&min=0&sec=0&p1=188 1000 EDT] | * Call convened at [http://timeanddate.com/worldclock/fixedtime.html?month=07&day=24&year=2007&hour=10&min=0&sec=0&p1=188 1000 EDT] | ||
| + | * Call-in: '''613.287.8000''' or '''866.362.7064''', passcode '''892048#''' | ||
| + | * Previous Meeting: [[Orbit Minutes 070626]] | ||
| + | <!-- | ||
* Client call setup: [[Asterisk Conference Calls]] | * Client call setup: [[Asterisk Conference Calls]] | ||
* Conf id: 8978 | * Conf id: 8978 | ||
* PIN: 82713 | * PIN: 82713 | ||
| − | + | --> | |
| − | + | ||
== Attendees == | == Attendees == | ||
Revision as of 08:21, 23 July 2007
- Call convened at 1000 EDT
- Call-in: 613.287.8000 or 866.362.7064, passcode 892048#
- Previous Meeting: Orbit Minutes 070626
Contents
Attendees
- TBD
Discussion
Manifest Files
Based on the results of the Orbit test suite, there are a bunch of failures because the bundles don't contain a manifest file. Further investigation shows that a manifest is there, but is of the wrong casing. (e.g. Mainfest.mf) When we look at CVS, the manifest looks ok so we need to determine where in the build process the problem occurs.
Bundle downloads
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? Some of the issues are described here: Orbit Bundle Layout.
R-builds
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
Next Meeting
- TBD