Skip to main content

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.

Jump to: navigation, search

Difference between revisions of "Orbit Minutes 061107"

 
Line 1: Line 1:
−
* Call convened at 1100EST
+
* Call convened at [http://timeanddate.com/worldclock/fixedtime.html?month=11&day=7&year=2006&hour=11&min=0&sec=0&p1=188 1100 EST]
 +
* Call-in: '''613.287.8000''' or '''866.362.7064''', passcode '''874551#'''
 +
* Previous Meeting: http://eclipse.org/orbit/documents/minutes-061024.php
  
 
== Attendees ==
 
== Attendees ==
  
 
* Jeff McAffer
 
* Jeff McAffer
−
* Bjorn Freeman-Benson
+
* David Williams
−
* Christian Damus
+
 
* John Graham
 
* John Graham
 
* DJ Houghton
 
* DJ Houghton
−
* Hubert Leung
 
−
* Pascal Rapicault
 
 
* Scott Lewis
 
* Scott Lewis
 +
* Hurbert Leung
 +
* Bjorn Freeman-Benson
 +
* Christian Damus
 
* Simon Kaegi
 
* Simon Kaegi
 +
* Pascal Rapicault
 +
* Tom Watson
 
* Martin Oberhuber
 
* Martin Oberhuber
−
* David Williams
 
  
 
== Discussion ==
 
== Discussion ==
 +
  
 
* '''Review action items from last call'''
 
* '''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. [https://bugs.eclipse.org/bugs/show_bug.cgi?id=163746 Bug 163746] <div style="border: 2px solid #8E87EB; padding: 6px;"> Pascal confirmed that existing bundles are not downloaded again</div>
+
** 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 for Orbit bundles.  <div style="border: 2px solid #8E87EB; padding: 6px;">No progress on wiki.  Simon has added source for many bundles in the repo.  Looking to make some progress on the wiki today.  Simon will also propose a template for the about files so that new projects have a hope of getting it right.</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 [https://bugs.eclipse.org/bugs/show_bug.cgi?id=163745 Bug 163745]  <div style="border: 2px solid #8E87EB; padding: 6px;">Some progress as far as design.  Looking to have the real build setup running by Jan 1. </div> <div style="border: 2px solid #FF0000; padding: 6px;">Action: David to setup a basic build for use in the mean time</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;">Jeff reviewed with Adrian and confirmed that there are no particular issues.  The Eclipse project already ships features that consolidate several third party libs under a variety of licenses.  Simon will produce a template for the about files.</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>
  
−
* '''Bundle naming''' The [Bundle Naming] conventions call for bundles to be named after the dominant package in a library.  This works reasonably well but there are "legacy" cases such as [https://bugs.eclipse.org/bugs/show_bug.cgi?id=163693 Ant] and [https://bugs.eclipse.org/bugs/show_bug.cgi?id=163692 JUnit] that work less well.  We need to agree on an approach for naming these bundles.
+
* '''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.
−
** Lots of discussion
+
** Much discussion.
−
** General reconfirmation of using the dominant package name approach
+
** 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.
−
** In cases where the dominiant package is "malformed" (e.g., Junit uses just "junit") we will, on a case by case basis, create a well-formed bundle symbolic name that is as close as possible to the originator's package naming.
+
** Conversation diverged somewhat into related topics.
−
**  For existing bundles whose names do not follow these conventions (e.g., Ant, JUnit 4) we discussed whether we should go for consistency or leave well enough alone.  The consensus was that all bundles in Orbit should follow the conventions and where that requires a change in the name of an existing bundle (e.g., org.junit4 => org.junit  version 4) we can provide a compatibility wrapper bundle that has the old name and requires and reexports the new bundle.   
+
** Do we need to review contributions before they are made?  No.  Contribute and work through the issues (see vetting point below).
−
<div style="border: 2px solid #FF0000; padding: 6px;">Action: DJ to test the wrappering and see if there are any issues.</div>
+
** Who are the committers? They are the committers on other projects who would be doing this work anyway.
−
<div style="border: 2px solid #FF0000; padding: 6px;">Action: Jeff to work with the PDE team to ensure that having multiple versions of the same bundle will work smoothly.</div>
+
** 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>
  
−
* Bundle registry
+
* '''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.
−
** There was some discussion around the need to expose which versions of which libraries are currently in Orbit.  This is needed both for people to understand what is being worked on but also what is available for download.
+
** 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.
−
** Agreed that each project should have a file in the HEAD branch that notes what branches there are.
+
** Pascal "volunteered" to help figure out the requirements and solutions related to PDE Build.
−
** Each branch should then also have a readme.xml (or some such) to hold information such as version number, status, license, etc
+
 
−
** We can then create a server side tool that runs over the projects and gets all the files from the various branches and generates a table.
+
* '''How are new contributions vetted'''
−
** The downloads page will end up having a table of available (built) versions
+
** Some people proposed that new contributions should be added to bugzilla and then reviewed and eventually committed to CVS.
−
<div style="border: 2px solid #FF0000; padding: 6px;">Action: Jeff to setup another call in three weeks.</div>
+
** 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 ==
 
== 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
 +
 +
== Next Meeting ==
 +
* [http://timeanddate.com/worldclock/fixedtime.html?month=11&day=21&year=2006&hour=11&min=0&sec=0&p1=188 Nov 21, 2006 at 1100 EST], Agenda: [[Orbit Minutes 061121]]
  
−
* Simon to creaate a wiki page on how to manage source for Orbit bundles.  * David and Bjorn to start setting up the build
+
[[Category:Orbit]]
−
* Jeff to work with the PDE team to ensure that having multiple versions of the same bundle will work smoothly.
+
[[Category:Orbit/Meeting]]
−
* Jeff to setup another call in three weeks.
+
[[Category:Meeting]]
−
* DJ to test the wrappering
+
−
* David to setup a basic build for use in the mean time
+

Latest revision as of 14:41, 21 November 2006

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
  • 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.
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

Next Meeting

Retrieved from "https://wiki.eclipse.org/index.php?title=Orbit_Minutes_061107&oldid=18100"

This page was last modified 14:41, 21 November 2006 by Jeff McAffer. Based on work by Martin Oberhuber and Christian W. Damus.

Back to the top