| 28 |
<td width="98%"> |
<td width="98%"> |
| 29 |
<b>Topics</b> |
<b>Topics</b> |
| 30 |
<ul> |
<ul> |
|
<li><a href="#FIXES">Upcoming Fixes</a></li> |
|
| 31 |
<li><a href="#BUILDS">Build Submissions</a></li> |
<li><a href="#BUILDS">Build Submissions</a></li> |
| 32 |
<li><a href="#INSTALLING">Installing Release Engineering Tools</a></li> |
<li><a href="#INSTALLING">Installing Release Engineering Tools</a></li> |
| 33 |
<li><a href="#RELENGMAP">Making a Build Submission with Release |
<li><a href="#RELENGMAP">Making a Build Submission with Release |
| 38 |
</td> |
</td> |
| 39 |
</tr> |
</tr> |
| 40 |
</table> |
</table> |
|
<a name="FIXES"> |
|
|
<table border=0 cellspacing=5 cellpadding=2 width="100%"> |
|
|
<tr> |
|
|
<td align=LEFT valign=TOP bgcolor="#0080C0"> |
|
|
<b><font color="#FFFFFF" face="Arial,Helvetica">Upcoming Fixes</font></b> |
|
|
</td> |
|
|
</tr> |
|
|
<tr> |
|
|
<td width="98%"> |
|
|
<p>If you're lucky, then there is a <a href="fixedBugs.html">list of |
|
|
fixes</a> that are expected to appear in the next integration |
|
|
build.</p> |
|
|
</td> |
|
|
</tr> |
|
|
</table> |
|
| 41 |
<a name="BUILDS"> |
<a name="BUILDS"> |
| 42 |
<table border=0 cellspacing=5 cellpadding=2 width="100%"> |
<table border=0 cellspacing=5 cellpadding=2 width="100%"> |
| 43 |
<tr> |
<tr> |
| 90 |
</tr> |
</tr> |
| 91 |
<tr> |
<tr> |
| 92 |
<td> |
<td> |
|
<p>Before performing an build submission, it is the responsibility of |
|
|
the submitter to verify that the UI tests all pass. To perform a |
|
|
submission using the releng tool, please do as follows:</p> |
|
| 93 |
<ol> |
<ol> |
| 94 |
<li>Select the project you need to version, and select "Team > |
<li>Make sure that you workspace contains all of the plug-ins |
| 95 |
Release".</li> |
contained in our modules. This includes <code>plat-ui</code>, |
| 96 |
|
<code>plat-ui-examples</code> and <code>plat-ui-tests</code>. Make |
| 97 |
|
sure to include fragments that are not appropriate for your |
| 98 |
|
platform, as they may need to be versioned as well.</li> |
| 99 |
|
<li>Get rid of all outgoing changes in your workspace.</li> |
| 100 |
|
<li>Run all the test suites. The definitive list of test suites is |
| 101 |
|
given by inspecting the <code>test.xml</code> files in all our test |
| 102 |
|
plug-ins. At the time of writing, they are roughly: databinding |
| 103 |
|
tests, navigator tests, parts references tests, session tests, |
| 104 |
|
rcp tests, JFace tests, and the rather large UiTestSuite. <em>Be |
| 105 |
|
careful not to disturb focus while the test are running. If you're |
| 106 |
|
leaving the machine running, you may wish to increase the time it |
| 107 |
|
takes for the screensaver to kick in.</em></li> |
| 108 |
|
<li>Run the <a href="cvs-comment.sh">build notes script</a>. On |
| 109 |
|
Windows XP, I would recommend installing <a |
| 110 |
|
href="http://www.cygwin.com">cygwin</a>. Check to make sure the |
| 111 |
|
list of bugs fixed makes sense.</li> |
| 112 |
|
<li>Update the <code>buildnotes_workbench.html</code> file with the |
| 113 |
|
results of the build scripts. Commit to CVS.</li> |
| 114 |
|
<li>Select a project in the Package Explorer, right-click and select |
| 115 |
|
"Team > Release".</li> |
| 116 |
|
<li>Use the default map project, and then select all the projects in |
| 117 |
|
the "ui.map" file.</li> |
| 118 |
|
<li>If the release is small, it is a good idea to check the list of |
| 119 |
|
changes.</li> |
| 120 |
<li>Supply the name of the release. Our convention is to use |
<li>Supply the name of the release. Our convention is to use |
| 121 |
vYYYYMMDDHHHH, where this the date and the time of the build. If the |
TYYYYMMDD-HHHH, where T is the type (e.g., I for an integration |
| 122 |
name is already in use, then use a letter suffix (i.e., a, b, c, |
build), YYYY is the year, MM is the month, DD is the day and HHHH is |
| 123 |
etc.).</li> |
the hour the build is scheduled to start. If the name is already in |
| 124 |
<li>The synchronize view will open showing the changes in the file |
use, then use a letter suffix (i.e., a, b, c, etc.).</li> |
| 125 |
"<code>ui.map</code>".</li> |
<li>As the commit comment, enter the information from the build |
| 126 |
<li>Continue to version all of the packages that you need.</li> |
notes script.</li> |
| 127 |
<li>When you are done, commit the changes to "<code>ui.map</code>". |
<li>Send an email to <a |
| 128 |
|
href="mailto:platform-ui-dev@eclipse.org">platform-ui-dev</a> with |
| 129 |
|
the information from the build notes script.</li> |
| 130 |
</ol> |
</ol> |
| 131 |
</td> |
</td> |
| 132 |
</tr> |
</tr> |
| 140 |
</tr> |
</tr> |
| 141 |
<tr> |
<tr> |
| 142 |
<td> |
<td> |
| 143 |
<p>To do a build submission using CVS, please do as follows:</p> |
<p>To do a build submission using CVS, use the above steps above, but do |
| 144 |
|
the following instead of using the releng tool:</p> |
| 145 |
<ol> |
<ol> |
| 146 |
<li>Tag all projects you have changed with the name of the release. Our |
<li>Tag all projects you have changed with the name of the release. Our |
| 147 |
convention is to use vYYYYMMDDHHHH, where this the date and time of the |
convention is to use TYYYYMMDD-HHHH, where T is the type (e.g., I for an |
| 148 |
build. If the name is already in use, then use a letter suffix (i.e., |
integration build), YYYY is the year, MM is the month, DD is the day and |
| 149 |
a, b, c, etc.).</li> |
HHHH is the hour the build is scheduled to start. If the name is already |
| 150 |
|
in use, then use a letter suffix (i.e., a, b, c, etc.).</li> |
| 151 |
<li>Checkout "org.eclipse.releng".</li> |
<li>Checkout "org.eclipse.releng".</li> |
| 152 |
<li>Open "<code>maps/ui.map</code>".</li> |
<li>Open "<code>maps/ui.map</code>".</li> |
| 153 |
<li>Change the version(s) of the project(s) you have tagged.</li> |
<li>Change the version(s) of the project(s) you have tagged.</li> |
| 167 |
</tr> |
</tr> |
| 168 |
<td> |
<td> |
| 169 |
<p>In the event of a test failure, our team must respond to |
<p>In the event of a test failure, our team must respond to |
| 170 |
<a href="mailto:eclipse-dev@eclipse.org">eclipse-dev</a> with one of two |
<a href="mailto:platform-releng-dev@eclipse.org">platform-releng-dev</a> |
| 171 |
responses. We can say that we want a recovery build the following day. |
with one of two responses. We can say that we want a recovery build the |
| 172 |
Alternatively, we can say that the test failure is not significant, and |
following day. Alternatively, we can say that the test failure is not |
| 173 |
that the quality of the build should not be affected. (In either case, a |
significant, and that the quality of the build should not be affected. |
| 174 |
bug should likely be entered into the bug database.)</p> |
(In either case, a bug should likely be entered into the bug |
| 175 |
|
database.)</p> |
| 176 |
<p>A recovery build can also be requested if there is a problem affecting |
<p>A recovery build can also be requested if there is a problem affecting |
| 177 |
the usability of the build. This problem should make the build unusable |
the usability of the build. This problem should make the build unusable |
| 178 |
for testing and development use.</p> |
for testing and development use.</p> |
Parent Directory
| 
Revision Log
| 
Patch