| <?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 "containing" 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); |
| ?> |