blob: af4d53f3fabc624ca835bd939df7a659fd5f9b2b [file] [log] [blame]
<?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);
?>