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 061107"
m (→Attendees) |
|||
| Line 1: | Line 1: | ||
| − | + | * Call convened at 1100EST | |
| − | + | ||
| − | * | + | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
== Attendees == | == Attendees == | ||
| Line 23: | Line 8: | ||
* DJ Houghton | * DJ Houghton | ||
* Scott Lewis | * Scott Lewis | ||
| − | * | + | * Hurbert Leung |
* Bjorn Freeman-Benson | * Bjorn Freeman-Benson | ||
* Christian Damus | * Christian Damus | ||
| Line 33: | Line 18: | ||
== Discussion == | == Discussion == | ||
| − | * | + | |
| + | * '''Review action items from last call''' | ||
| + | ** Pascal to confirm that Update Manager does not download a new copy of a bundle that is already installed. <div style="border: 2px solid #8E87EB; padding: 6px;">partial verification. needs to confirm but assumption that it does not redownload. Opened a [https://bugs.eclipse.org/bugs/show_bug.cgi?id=163746 bug report] to track this.</div> | ||
| + | ** Simon to start a wiki page on how to manage source some orbit bundles <div style="border: 2px solid #8E87EB; padding: 6px;">The general proposal is to have src.zips in the binary projects. There is a wiki page on a new strategy for [[Source Bundles | shipping source]] but nothing specific to how source is handled in Orbit. We may need to consider PDE build changes for creating the appropriate source bundles. For now start by putting source in the bundles as normal (i.e., as src.zip files) and then figure out how to distribute the source for real.</div> | ||
| + | ** David and Bjorn to start setting up the build <div style="border: 2px solid #8E87EB; padding: 6px;">David wonders how that is going. :-) Webmasters have setup dirs at build.eclipse.org/orbit. David suggests that we follow in the WTP footsteps and have the build kick off when a map file changes. Opened a [https://bugs.eclipse.org/bugs/show_bug.cgi?id=163745 bug report] to track this.</div> | ||
| + | ** Jeff to confirm the legal requirements in this area <div style="border: 2px solid #8E87EB; padding: 6px;">No action</div> | ||
| + | ** Jeff to schedule next call <div style="border: 2px solid #8E87EB; padding: 6px;">completed</div> | ||
| + | |||
| + | * '''How are committers added?''' To date committers have been coming with "initial contributions" and we have been voting on adding them. David Williams pointed out that this might be too much process since the contributions are acceptable if they have been approved by the EMO. | ||
| + | ** Much discussion. | ||
| + | ** General consensus that no vote is needed and the project lead manages the addition of committers. General expectation that there be at most one or two committers from each Eclipse project. | ||
| + | ** Conversation diverged somewhat into related topics. | ||
| + | ** Do we need to review contributions before they are made? No. Contribute and work through the issues (see vetting point below). | ||
| + | ** Who are the committers? They are the committers on other projects who would be doing this work anyway. | ||
| + | ** Is it projects committing to a lib or an individual? It should be the individual since there is no structure to have a project commit to something. | ||
| + | ** What happens if several projects want different versions? This is fine though they would be encouraged to settle on a common version. | ||
| + | ** It was proposed that we list the maintainers for individual bundles. General consensus that this is a good idea. | ||
| + | ** How should we start contributing? General agreement that you start by opening a bug report stating the lib and version you want to contribute as well as referencing the Foundation approval information and the associated project. We deferred discussion about exact content and format of this information until more is known about how this all fits together. | ||
| + | <div style="border: 2px solid #FF0000; padding: 6px;">Action: Bjorn to get the list of libs already approved and who is approved to use etc.</div> | ||
| + | |||
| + | * '''Working in branches or multiple projects for one library?''' The current approach is to work in a branch and have head be empty. Check out HEAD and Replace With the appropriate branch. | ||
| + | ** Bjorn questioned the impact on the build system. Using a different branch or different project is not the issue. Using different bundle ids is the issue. PDE Build currently cannot build multiple of the same bundle. | ||
| + | ** Pascal "volunteered" to help figure out the requirements and solutions related to PDE Build. | ||
| + | |||
| + | * '''How are new contributions vetted''' | ||
| + | ** Some people proposed that new contributions should be added to bugzilla and then reviewed and eventually committed to CVS. | ||
| + | ** It was observed that this made it hard to do the reviews and actually work with the bundles. | ||
| + | ** General consensus that we should commit contributions when they are in a reasonable state and then polish with the help of and feedback from the community. Notification to the mailing list etc. on commit would be very useful here. | ||
| + | ** Will there be a release review of orbit? Bjorn stated that there is no need of a release review for Orbit as each consuming project will be reviewed | ||
| + | ** Pascal: projects release at different points and so consume Orbit parts at different points in time. The consuming project's release review should reveal any issues | ||
| + | |||
| + | * '''Maintaining the IP log''' | ||
| + | ** Yes, we should do this. Exact form was left up in the air but there appeared to be a general consensus that a file in each project should outline IPzilla referneces, consuming projects and maintainers. | ||
| + | ** Would be good to have some infrastructure to generate the table of libs, versions, users, ... | ||
| + | ** Suggested and accepted that we defer putting such infrastructure in place until we know more about the shape and requirements. | ||
| + | |||
| + | * '''Source bundles''' | ||
| + | ** Simon detailed what he has done for several projects already. | ||
| + | *** Add a note about the source in the about.html (either stating its presence or at least some suggestion of where the source can be found) | ||
| + | *** If possible package source in src.zip at the root of the project | ||
| + | *** Adjust .classpath and build.properties to reflect the addition of src.zip | ||
| + | ** General consensus that this was a reasonable starting point and that having source available was a good thing | ||
| + | ** Also agreed that "source" means Java and perhaps some resources. There is no need or desire to be able to build from the supplied source. The purpose of supplying source is to aid in programming and debugging with the lib, not developing the lib itself. | ||
| + | |||
| + | <div style="border: 2px solid #FF0000; padding: 6px;">Action: Jeff to setup another call in two weeks.</div> | ||
| + | |||
| + | == Open Action Items == | ||
| + | * Pascal to confirm that Update Manager does not download a new copy of a bundle that is already installed. [https://bugs.eclipse.org/bugs/show_bug.cgi?id=163746 Bug 163746] | ||
| + | * Simon to start a wiki page on how to manage source some orbit bundles | ||
| + | * David and Bjorn to start setting up the build [https://bugs.eclipse.org/bugs/show_bug.cgi?id=163745 Bug 163745] | ||
| + | * Jeff to confirm the legal requirements in this area | ||
| + | * Jeff to schedule next call in two weeks | ||
Revision as of 23:53, 7 November 2006
- Call convened at 1100EST
Attendees
- Jeff McAffer
- David Williams
- John Graham
- DJ Houghton
- Scott Lewis
- Hurbert Leung
- Bjorn Freeman-Benson
- Christian Damus
- Simon Kaegi
- Pascal Rapicault
- Tom Watson
- Martin Oberhuber
Discussion
- Review action items from last call
- Pascal to confirm that Update Manager does not download a new copy of a bundle that is already installed. partial verification. needs to confirm but assumption that it does not redownload. Opened a bug report to track this.
- Simon to start a wiki page on how to manage source some orbit bundles The general proposal is to have src.zips in the binary projects. There is a wiki page on a new strategy for shipping source but nothing specific to how source is handled in Orbit. We may need to consider PDE build changes for creating the appropriate source bundles. For now start by putting source in the bundles as normal (i.e., as src.zip files) and then figure out how to distribute the source for real.
- David and Bjorn to start setting up the build David wonders how that is going. :-) Webmasters have setup dirs at build.eclipse.org/orbit. David suggests that we follow in the WTP footsteps and have the build kick off when a map file changes. Opened a bug report to track this.
- Jeff to confirm the legal requirements in this area No action
- Jeff to schedule next call completed
- Pascal to confirm that Update Manager does not download a new copy of a bundle that is already installed.
- How are committers added? To date committers have been coming with "initial contributions" and we have been voting on adding them. David Williams pointed out that this might be too much process since the contributions are acceptable if they have been approved by the EMO.
- Much discussion.
- General consensus that no vote is needed and the project lead manages the addition of committers. General expectation that there be at most one or two committers from each Eclipse project.
- Conversation diverged somewhat into related topics.
- Do we need to review contributions before they are made? No. Contribute and work through the issues (see vetting point below).
- Who are the committers? They are the committers on other projects who would be doing this work anyway.
- Is it projects committing to a lib or an individual? It should be the individual since there is no structure to have a project commit to something.
- What happens if several projects want different versions? This is fine though they would be encouraged to settle on a common version.
- It was proposed that we list the maintainers for individual bundles. General consensus that this is a good idea.
- How should we start contributing? General agreement that you start by opening a bug report stating the lib and version you want to contribute as well as referencing the Foundation approval information and the associated project. We deferred discussion about exact content and format of this information until more is known about how this all fits together.
Action: Bjorn to get the list of libs already approved and who is approved to use etc.
- Working in branches or multiple projects for one library? The current approach is to work in a branch and have head be empty. Check out HEAD and Replace With the appropriate branch.
- Bjorn questioned the impact on the build system. Using a different branch or different project is not the issue. Using different bundle ids is the issue. PDE Build currently cannot build multiple of the same bundle.
- Pascal "volunteered" to help figure out the requirements and solutions related to PDE Build.
- How are new contributions vetted
- Some people proposed that new contributions should be added to bugzilla and then reviewed and eventually committed to CVS.
- It was observed that this made it hard to do the reviews and actually work with the bundles.
- General consensus that we should commit contributions when they are in a reasonable state and then polish with the help of and feedback from the community. Notification to the mailing list etc. on commit would be very useful here.
- Will there be a release review of orbit? Bjorn stated that there is no need of a release review for Orbit as each consuming project will be reviewed
- Pascal: projects release at different points and so consume Orbit parts at different points in time. The consuming project's release review should reveal any issues
- Maintaining the IP log
- Yes, we should do this. Exact form was left up in the air but there appeared to be a general consensus that a file in each project should outline IPzilla referneces, consuming projects and maintainers.
- Would be good to have some infrastructure to generate the table of libs, versions, users, ...
- Suggested and accepted that we defer putting such infrastructure in place until we know more about the shape and requirements.
- Source bundles
- Simon detailed what he has done for several projects already.
- Add a note about the source in the about.html (either stating its presence or at least some suggestion of where the source can be found)
- If possible package source in src.zip at the root of the project
- Adjust .classpath and build.properties to reflect the addition of src.zip
- General consensus that this was a reasonable starting point and that having source available was a good thing
- Also agreed that "source" means Java and perhaps some resources. There is no need or desire to be able to build from the supplied source. The purpose of supplying source is to aid in programming and debugging with the lib, not developing the lib itself.
- Simon detailed what he has done for several projects already.
Action: Jeff to setup another call in two weeks.
Open Action Items
- Pascal to confirm that Update Manager does not download a new copy of a bundle that is already installed. Bug 163746
- Simon to start a wiki page on how to manage source some orbit bundles
- David and Bjorn to start setting up the build Bug 163745
- Jeff to confirm the legal requirements in this area
- Jeff to schedule next call in two weeks