| <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> |
| <html> |
| <head> |
| <meta content="text/html; charset=ISO-8859-1" |
| http-equiv="content-type"> |
| <title>child workspace policies</title> |
| <meta http-equiv="CONTENT-TYPE" content="text/html; charset=utf-8"> |
| </head> |
| <body> |
| <h1>How to Introduce a New Module on a Child Workspace</h1> |
| <p>Version 15.12.2004</p> |
| <p> |
| <p> In case you have to introduce a new module not yet known on the |
| master workspace you have to </p> |
| <ul> |
| <li> create that module in cvs. </li> |
| <li>get a cvs alias for that module so that it can be checked out by |
| it's name. </li> |
| <li> check in for this module to cvs HEAD in your CWS. In contrast to |
| all added modules do not work on a cws-branch but toplevel. </li> |
| <li> assure inter module dependencies (i.e. build.lst files) are |
| correct. Make sure all modules needing something delivered by the new |
| one are dependend on it. If it is not needed by any module at build |
| time, make it a prerequisite of 'postprocess'. </li> |
| <li> when the cws is in QA, announce the new module to Hamburg release |
| engineering. You can do this either by writing something in the CWS |
| description field (to RE: CWS contains new module bla) or by sending an |
| email. This is necessary because new modules do not get tracked by CWS |
| tooling and RE has to manually check them out before doing the |
| integration build on the master workspace.<br> |
| </li> |
| </ul> |
| </body> |
| </html> |
