platform-ui-home/builds/index.html
Parent Directory
| 
Revision Log
Revision 1.13 -
(download)
(as text)
(annotate)
Wed Apr 26 20:46:42 2006 UTC (3 years, 7 months ago) by pwebster
Branch: MAIN
CVS Tags: HEAD
Changes since 1.12: +1 -1 lines
Wed Apr 26 20:46:42 2006 UTC (3 years, 7 months ago) by pwebster
Branch: MAIN
CVS Tags: HEAD
Changes since 1.12: +1 -1 lines
minor change to accomodate cygwin
<html> <head> <title>Builds (Platform-UI)</title> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> <link rel="stylesheet" href="http://dev.eclipse.org/default_style.css" type="text/css"> </head> <body bgcolor="#FFFFFF" text="#000000"> <table border=0 cellspacing=5 cellpadding=2 width="100%"> <tr> <td align=left width="72%"> <font class=indextop>Builds</font><br> <font class=indexsub>platform user interface</font> </td> <td width="28%"> <img src="http://dev.eclipse.org/images/Idea.jpg" height=86 width=120 alt="Eclipse documentation banner"> </td> </tr> </table> <table border=0 cellspacing=5 cellpadding=2 width="100%"> <tr> <td align=LEFT valign=TOP bgcolor="#0080C0"> <b><font color="#FFFFFF" face="Arial,Helvetica">Topics</font></b> </td> </tr> <tr> <td width="98%"> <b>Topics</b> <ul> <li><a href="#BUILDS">Build Submissions</a></li> <li><a href="#INSTALLING">Installing Release Engineering Tools</a></li> <li><a href="#RELENGMAP">Making a Build Submission with Release Engineering Tools</a></li> <li><a href="#CVSMAP">Making a Build Submission with CVS Only</a></li> <li><a href="#RECOVERY">Recovery Builds</a></li> </ul> </td> </tr> </table> <a name="BUILDS"> <table border=0 cellspacing=5 cellpadding=2 width="100%"> <tr> <td align=LEFT valign=TOP bgcolor="#0080C0"> <b><font color="#FFFFFF" face="Arial,Helvetica">Build Submissions</font></b> </td> </tr> <tr> <td width="98%"> <p>Build submissions are done before every integration build and milestone build. Integration builds typically occur on Tuesday. Please see the <a href="http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-releng-home/index.html">Platform Release Engineering</a> page for more information. We do our build submission for an 8 a.m. build, at 4 p.m. the previous day.</p> <p>If you miss the cut-off for the official build submission, but it is still before the build has started, then you can do your own build submission to make sure your fix gets into the build.</p> <p>A warning email should be sent to "platform-ui-dev@eclipse.org" (or all committers) at the beginning of the days on which an official build submission is to occur, or if you do your own build submission.</p> </tr> </table> <a name="INSTALLING"> <table border=0 cellspacing=5 cellpadding=2 width="100%"> <tr> <td align=LEFT valign=TOP bgcolor="#0080C0"> <b><font color="#FFFFFF" face="Arial,Helvetica">Installing the Release Engineering Tool</font></b> </td> </tr> <tr> <td> <p>The Platform-UI team suggests that the Release Engineering (releng) tool be installed before doing a build submission. It reduces the chance of error.</p> <ol> <li>Exit Eclipse (if running)</li> <li>Download the <a href="http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-releng-home/org.eclipse.releng.tools_3.1.0.zip">releng tool</a>.</li> <li>Unzip the tool into your <code>plugins</code> directory.</li> <li>Start Eclipse</li> </ol> </td> </tr> </table> <a name="RELENGMAP"> <table border=0 cellspacing=5 cellpadding=2 width="100%"> <tr> <td align=LEFT valign=TOP bgcolor="#0080C0"> <b><font color="#FFFFFF" face="Arial,Helvetica">Making a Build Submission with the Release Engineering Tool</font></b> </td> </tr> <tr> <td> <ol> <li>Make sure that your workspace contains all of the plug-ins contained in our modules. This includes <code>plat-ui</code>, <code>plat-ui-examples</code> and <code>plat-ui-tests</code>. Make sure to include fragments that are not appropriate for your platform, as they may need to be versioned as well. Check out the project <code>org.eclipse.releng</code> from HEAD. </li> <li>Get rid of all outgoing changes in your workspace.</li> <li>Run all the test suites. The definitive list of test suites is given by inspecting the <code>test.xml</code> files in all our test plug-ins. At the time of writing, they are roughly: databinding tests, navigator tests, parts references tests, session tests, rcp tests, JFace tests, tabbed properties view tests, and the rather large UiTestSuite. There are launch configurations that you can find in the debug/run launch dialog when you load all the test projects. You can use these to run the tests, rather than creating new ones. <em>Be careful not to disturb focus while the test are running. If you're leaving the machine running, you may wish to increase the time it takes for the screensaver to kick in.</em></li> <li>Run the <a href="cvs-comment.sh">build notes script</a>. On Windows XP, I would recommend installing <a href="http://www.cygwin.com">cygwin</a>. Check to make sure the list of bugs fixed makes sense. To run the build script, execute the following: <br> <em> /bin/bash cvs-comment.sh TYYYYMMDD-HHHH HEAD workspace-location > log.txt</em><br> where TYYYYMMDD-HHHH is when the build is scheduled to start, HEAD is the stream to check, workspace location is the directory that contains the build workspace, and log.txt is the file to which the results will be written.</li> <li>Update the <code>org.eclipse.ui/buildnotes_workbench.html</code> file with the results of the build scripts. Commit to CVS.</li> <li>Select a project in the Package Explorer, right-click and select "Team > Release".</li> <li>Use the default map project, and then select all the projects in the "ui.map" file.</li> <li>If the release is small, it is a good idea to check the list of changes.</li> <li>Supply the name of the release. Our convention is to use TYYYYMMDD-HHHH, where T is the type (e.g., I for an integration build), YYYY is the year, MM is the month, DD is the day and HHHH is the hour the build is scheduled to start. If the name is already in use, then use a letter suffix (i.e., a, b, c, etc.).</li> <li>As the commit comment, enter the information from the build notes script.</li> <li>Send an email to <a href="mailto:platform-ui-dev@eclipse.org">platform-ui-dev</a> with the information from the build notes script.</li> </ol></td> </tr> <tr> <td> </td> </tr> </table> <a name="CVSMAP"> <table border=0 cellspacing=5 cellpadding=2 width="100%"> <tr> <td align=LEFT valign=TOP bgcolor="#0080C0"> <b><font color="#FFFFFF" face="Arial,Helvetica">Making a Build Submission with CVS Only</font></b> </td> </tr> <tr> <td> <p>To do a build submission using CVS, use the above steps above, but do the following instead of using the releng tool:</p> <ol> <li>Tag all projects you have changed with the name of the release. Our convention is to use TYYYYMMDD-HHHH, where T is the type (e.g., I for an integration build), YYYY is the year, MM is the month, DD is the day and HHHH is the hour the build is scheduled to start. If the name is already in use, then use a letter suffix (i.e., a, b, c, etc.).</li> <li>Checkout "org.eclipse.releng".</li> <li>Open "<code>maps/ui.map</code>".</li> <li>Change the version(s) of the project(s) you have tagged.</li> <li>Save the map.</li> <li>Commit your changes to the map to CVS.</li> </ol> <p> </td> </tr> </table> <a name="RECOVERY"> <table border=0 cellspacing=5 cellpadding=2 width="100%"> <tr> <td align=LEFT valign=TOP bgcolor="#0080C0"> <b><font color="#FFFFFF" face="Arial,Helvetica">Recovery Builds</font></b> </td> </tr> <td> <p>In the event of a test failure, our team must respond to <a href="mailto:platform-releng-dev@eclipse.org">platform-releng-dev</a> with one of two responses. We can say that we want a recovery build the following day. Alternatively, we can say that the test failure is not significant, and that the quality of the build should not be affected. (In either case, a bug should likely be entered into the bug database.)</p> <p>A recovery build can also be requested if there is a problem affecting the usability of the build. This problem should make the build unusable for testing and development use.</p> <p>For a recovery build, the map will need to be updated to include our fixes. This can either be everything on the head in CVS, or just the particular fixes we need. The former should only be done if no risky changes have gone onto the head since the last (i.e., the failed) build submission.</p> </td> <tr> </tr> </table> </body> </html>
| help@eclipse.org | ViewVC Help |
| Powered by ViewVC 1.0.3 |