<?php require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/app.class.php");  require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/nav.class.php");   require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/menu.class.php");
$App   = new App();
$Nav  = new Nav();
$Menu   = new Menu();
include($App->getProjectCommon());

  #*****************************************************************************
  #
  #
  #****************************************************************************

  #
  # Begin: page-specific settings.  Change these.
  $pageTitle     = "Orbit Call Minutes 061024";
  $pageKeywords  = "Orbit, bundles, documents, minutes";

  # Add page-specific Nav bars here
  # Format is Link text, link URL (can be http://www.someothersite.com/), target (_self, _blank), level (1, 2 or 3)
  # $Nav->addNavSeparator("My Page Links",   "downloads.php");
  # $Nav->addCustomNav("My Link", "mypage.php", "_self", 3);
  # $Nav->addCustomNav("Google", "http://www.google.com/", "_blank", 3);

  # End: page-specific settings
  #

  # Paste your HTML content between the markers!
ob_start();
?>

  <div id="midcolumn">
    <h1><?= $pageTitle ?></h1>


Oct 24, 2006 @ 1400ET
<p><b>Jeff:</b> I am terrible at talking, thinking and typing all at the same time so
  these notes are rough and I may have misattributed comments etc. Please correct/clarify
  as you feel necessary.</p>
<h2>Attendees</h2>
<p>  Martin Oberhuber <br>
  Bjorn Freeman-Benson<br>
  David Williams<br>
  Jeff McAffer<br>
  Simon Kaegi<br>
  Pascal Rapicault</p>
<h2>Discussion</h2>
<p>A relatively free form discussion on issues and thoughts related to Orbit
  process and infrastructure.</p>
<p> <strong>Jeff:</strong> Set some context for Orbit, what it is, what it is not and who can/should
  participate<br>
   <strong>Martin:</strong> He is looking to join and commit Apache ORO and Commons Net. They
  are using these for their target management work in an upcoming 1.0 release.
  It would be good to leverage the naming conventions etc put forward in Orbit.<br>
   <strong>Jeff:</strong> This would be great and we should act on Martin's offer to participate
in the mailing list</p>
<p> <strong>David:</strong> should we have some review of the bundling and form? Having discussions
  beforehand would reduce churn.<br>
   <strong>Jeff:</strong> This makes sense and can feed into the best practices docs. People
should add sections to the Wiki or open discussions on the mailing list. </p>
<p> <strong>David:</strong> should we separate the pieces of the components we get from Apache
  etc. For example, Tomcat comes with several nested bits.<br>
   <strong>Jeff:</strong> This is a best practice item. Initial answer yes, we should seek to
componentize as much as possible.</p>
<p> <strong>Simon:</strong> should we use the qualifier segment in the version numbers? There
  is a concern that rebuilding will generate new versions with the same content<br>
   <strong>David:</strong> that won't happen unless the CVS tag changes. More generally we probably
  don't need nightly builds (which would have the characteristic Simon mentioned)
and just do all builds as Integration builds (i.e., identifying version tags)</p>
<p> <strong>Simon:</strong> how should we handle source for the libraries. We can include source
  zips in the projects or make a file that as a URL to the source<br>
   <strong>Jeff:</strong> The main purpose of having the source is so that people can get/install
  it and then use it for development/debugging. Currently that means delivering
  the source in bundles (in some form). Note also that the many projects do not
  provide source in an easily consumed way so just having a link to a zip on
  some server does not help alot.<br>
   <strong>Jeff:</strong> We should consider delivering the source in individual bundles and
  have them built as part of the build. We may need to tweak the build process
  to help but it should not be a major issue.<br>
  <strong> Action:</strong> Simon to start a wiki page on how to manage source</p>
<p><strong>David:</strong> how should we build the Orbit bundles? Proposal to build using the
  normal PDE build process that many projects are using today. <br>
   <strong>Discussion:</strong> how many map files will be needed etc. The challenge
  with more than one is how to decide where the entry for a particular bundle
  goes. Challenge with one is potential collisions during editing. Concluded
  that for now we'll go with just one and see if there are any issues.<br>
   <strong>Jeff:</strong> we should use the build infrastructure supplied by the Foundation.<br>
   <strong> Action:</strong> David and Bjorn to start setting up the build</p>
<p> <strong>David:</strong> How many features will be needed? One per bundle? One for all of
  Orbit? None?<br>
   <strong>David:</strong> is there a legal obligation to expose the licensing via features in
  the Update workflow. WTP uses one feature per thirdparty lib<br>
   <strong>Jeff:</strong> Don't believe there is a legal obligation. The Eclipse project aggregates
  the third party license references in the &quot;containing&quot; features and
  so does not have a feature per lib<br>
  <strong>Action:</strong> Jeff to confirm the legal requirements in this area </p>
<p> <strong>Jeff:</strong> Features are useful if we are going to have an update site. Some discussion
  about the uses of an update site.<br>
   <strong>David:</strong> Having separate features allows Update Manager to optimize the download
  and not download/install the same feature twice.<br>
   <strong>Pascal:</strong> Update manager does not duplicate the downloads<br>
   <strong>Action:</strong> Pascal to confirm that Update Manager does not download a new copy
of a bundle that is already installed.</p>
<p> <strong>Jeff:</strong> How do people want to consume Orbit bundles<br>
   <strong>David:</strong> input into the build. Some people have scripts that suck bundles from
  update sites. Project update sites are useful when creating the Europa update
site.<br>
   <strong>Jeff:</strong> End users will not go to an Orbit update site. They will use the product
  update site (e.g., Europa)<br>
   <strong>Conclusion:</strong> For now we will create a download site that includes
   individual
JARs as well as one zip of all bundles.</p>
<p><strong>Simon:</strong> should the manifests be locallized?<br>
   <strong>??:</strong> Yes.</p>
<p> <strong>David:</strong> We should ensure that the libs being committed here are traceable
  back to the Foundation approval. <br>
   <strong>Conclusion:</strong> The CVS commit comment should include a reference to the
IPzilla report associated with the library.</p>
<p> <strong>Group:</strong> Brief discussion around using CVS HEAD with different project names
  vs. Branches of one project for each version of a lib<br>
  <strong>Conclusion:</strong> use branches for now and revisit in a future call.</p>
<p> Call concluded. Jeff to schedule another call in 2-3 weeks. The time should
  be about 1100 ET to accomodate west coast and Europe.</p>
<h2>Action Items:</h2>
<p>  <strong>Action:</strong> Pascal to confirm that Update Manager does not download a new copy
      of a bundle that is already installed.<br>
      <strong>Action:</strong> Simon to start a wiki page on how to manage source<br>
   <strong>Action:</strong> David and Bjorn to start setting up the build<br>
   <strong>Action:</strong> Jeff to confirm the legal requirements in this area <br>
   <strong> Action:</strong> Jeff to schedule next call<br>
</p>


  </div>

<?php
  include $_SERVER['DOCUMENT_ROOT'] . "/orbit/global-links.html";
  include "dir-links.html";
?>

<?php
  $html = ob_get_clean();

  # Generate the web page
  $App->generatePage($theme, $Menu, $Nav, $pageAuthor, $pageKeywords, $pageTitle, $html);
?>