EIS

Overview

EIS (Environment Information System) consists of a database keeping information about MasterWorkspaces (short MWS) and ChildWorkspaces (short CWS) as well as some additional things, a web-frontend used by everyone involved with work on ChildWorkspaces ( eg. developer, QA member, Documentation writer, member of User Experience Team, those working on localization and internationalization etc. ) and a SOAP interface used by a bunch of commandline tools which are used by developers to create and maintain ChildWorkspaces.

You can log into the web frontend at http://eis.services.openoffice.org with your OOo email address (including @openoffice.org) and your OOo password. A read-only anonymous access is also available there.

EIS is also needed if you want to write feature mails or api changes to inform developers, Quality Assurance (QA) engineers, localization- (L10N) and documentation-people about changes in the office code or if you want to check Specifications.

Additionally EIS provides a few RSS feeds with information about ChildWorkspaces and [[MWS | MasterWorkspaces]. The feed that informs about new milestones on MasterWorkspaces for example is [http://en.wikipedia.org/wiki/Web_syndication syndicated on Planet OpenOffice.org. These can also be found on the main EIS page.

Background and general Information

Development on OpenOffice.org/StarOffice is using branches in the source code repository (currently CVS) a set of commandline tools and the tool called EIS. EIS is the acronym for Environment Information System and also the german word for the english word ice bye the way. The idea behind MasterWorkspaces (short MWS) and ChildWorkspaces (short CWS) is that no development is done on the MWS. Instead all work is performed on a copy of the MWS, this copy then is referred to as a CWS. Only if the CWS is at least as good as the MWS (it may contain no regressions and newly introduced features must be fully operational) it will be merged ( integrated) back into the MWS. Ideally this would mean that the MWS can be released at any time as a fully working drop. However, this only works in theory. Still the concept of MWS/CWS greatly reduces the number of new issues introduced in the MWS.

Codelines for releases use different MasterWorkspaces and for minor releases also a new MasterWorkspace is usually introduced to stabilize the code for this minor release on a separate branch.

To work with ChildWorkspaces and MasterWorkspaces means:

• To do all development work on a copy of the product code
• To thoroughly test and check the developed code before re-integrating it into the product code.
• Only fully tested source code gets into production code, so fewer regression bugs will occur.
• All milestones on the MasterWorkspace (the product code) are potentially in a condition to be published
• Bugs are more often discovered around the time they are introduced, and by the people who introduced them.
• Because code is better checked and tested before integrating it into the product, the developer has greater freedom to work

ChildWorkspaces in EIS do have a status which reflects what is currently being done on the ChildWorkspace and if the CWS has already gone into production code or the CWS is still being worked on. Which next status can be set depends on the current status.

There is a set of ChildWorkspace Policies which regulates how work on a ChildWorkspace is done eg. how issues in OpenOffice.org's bugtracking system issuezilla are usually assigned to ChildWorkspaces and how the different kinds of people involved in the lifecycle of a ChildWorkspace interact with each other. EIS knows about two different kinds of ChildWorkspaces: public CWS and Sun internal CWS. For Sun internal CWS only a limited set of information is being shown on http://eis.services.openoffice.org For example the description, which might contain internal information about a Sun customer, is not being shown. Sun internally there exists a different incarnation of the EIS web-frontend which does show this information. Most ChildWorkspaces being worked on by Sun developers are public, only those few containing StarOffice only modules or features or those which do contain confidential information about a Sun customer are private ChildWorkspaces. ChildWorkspaces always have an "Owner" and a "QA representative" which usually should be two distinct persons ;-). Other types of information kept in EIS are for example relevant source code modules, feature and/or bug-fix issues being worked on in the CWS, the release for which the CWS is planned to be integrated and flags to indicated wether changes on that CWS are relevant for Documentation and Translation. EIS also offers some statistics about ChildWorkspaces. Some fields in the Edit page for a CWS are required to be set at least when the status is changed to ready for QA and you will not be able to change to that state without setting those also. Besides the "Owner" and the "QA representative" EIS also provides the role of a "Member" of a ChildWorkspace. Members can be added on the CWS edit page. All CWS where you are either "Owner", "QA representative" or "Member" are shown on list provided by the ChildWorkspaces/MyCWS list. The "ChildWorkspaces/Browse" submenu provides some treeviews to show ChildWorkspaces in the database using different selection criterias. Which entries in this treeviews are shown is limited by a setting. The default is to show only CWS of the last 6 month. This can be changed by using the Settings link in the right corner and than using the CWS tab page where you will find a field "months displayed in treeviews" which can be set to a new value.

Additionally to the handling of ChildWorkspaces and MasterWorkspaces another feature of EIS is the handling of API Changes and Feature Announcements, which are entered into EIS by developers and than mailed to OpenOffice.org mailing lists and stored in the EIS database. API Changes inform other developers about code changes which might be relevant to them and Feature Announcements as well as Specifications are essential for those working on documentation or QA. Feature Announcements and Specifications are also used for semi-automated Release Notes creation and are thus important for informing everyone about changes in new releases, see OpenOffice.org 2.0.4 Release Notes for example. Specifications must be created using a standard template and EIS can check wether documents can be used for the Release Notes creation process or break that process because they do contain changes that make the document unusable for the XSLT being used for that or because they are not based on the correct template.

List of statuses know to EIS

1. planned: A CWS with this state is planned, but not physically existend. Thus no code has been changed, it´s not even yet decided from which milestone the CWS will be created. Having this state available is useful for long term planning, resource aquisition etc.
2. new: CWS with this state have been created, they do have a physical representation somewhere and development is currently working on it. The cwscreate commandline tool is used to create directory for source code of a new ChildWorkspace. If a ChildWorkspace with state planned and the name given as argument to cwscreate already exists this one is propagated to state new in EIS otherwise a new entry is created in EIS. If you create a ChildWorkspace using cwscreate please use the web frontend afterwards and add as much additional information as possible.
3. ready for qa: The developers think they are ready. They have prepared installation sets and hand the CWS over to QA by changing to this state. Depending on how the CWS handling for the MasterWorkspace is configured QA can now either set the state to nominated or approved by QA if QA accepts the changes on the ChildWorkspace. If changes on the CWS are note accepted QA sets the state back to new.
4. approved by QA: This is a special intermediate state used when a more controlled approach is active for the MasterWorkspace the CWS was created on. In this case QA approves a CWS but program management has the final say if and when something goes into the MasterWorkspace. That is program management will set the state to nominated after QA has set this state.
5. nominated: The CWS is being handed over to Release Engineering which can now start to integrate the CWS into the MasterWorkspace
6. integrated: all work on the CWS is finished and the changes on the ChildWorkspace have been integrated into the MasterWorkspace.
7. canceled: A canceled CWS has been abandoned, no more work will be done on it. This state is for CWS which where once in state new but are not needed anymore.
8. deleted: similar to canceled this is for CWS which are not needed any more. The difference is that the deleted state can only be set for planned CWS which never made it to being actually physically created and thuse to the state new.
9. fixed on master: this is used to reflect changes in EIS done by Release Engineering directly on the Master usually to fix a very special urgent problem or a merge conflict. CWS in this state are not really existing physically these are just entries in EIS keeping information about changes done directly on the source code repository branch of the MasterWorkspace.
10. finished: This is a special state used for Special-Product-Release ChildWorkspaces which will never get integrated into a MasterWorkspace but represent a Special Release Version, eg. some version done for a single customer with a change that will never get into the MasterWorkspace.
11. pre-nominated for PP: a historic state used for special Product Patch CWS handling, no longer used.
12. cloned: There are times when changes for a MasterWorkspace created to stabalize a minor release must also be integrated into a MasterWorkspace for the current main release trunk or vice versa. In this case ChildWorkspaces are being cloned. Eg. there can be a ChildWorkspace xyz created on the MasterWorkspace SRC680 and to integrate the same changes also into the OOE680 MasterWorkspace a clone xyz_OOE680 will be created. Release Engineering has a special commandline tool to create such clones.

EIS Entry Points

The main webpage for EIS is http://eis.services.openoffice.org. There you can find a link to EIS logon where you must use your OpenOffice.org email address as username. There is also an anonymous guest logon link on this page for those who do not have an OpenOffice.org account and the RSS feeds EIS provides can also be found on that page. Besides, the "Find a ChildWorkspace (CWS) name for a given IssueTracker issue ID", "List integrated issues within the most current CVS master build" and "Show treeview of all integrated CVS master builds" features on [ http://qa.openoffice.org/issuelinks.html http://qa.openoffice.org/issuelinks.html] are also features provided by EIS. At http://specs.openoffice.org there is a Specification Checking Tool link, which is also a feature offered by EIS. You may find direct links to ChildWorkspaceinformation in some RSS feeds and webpages like Planet OpenOffice.org or in some documentation on http://www.openoffice.org. If you need to create such a direct link to ChildWorkspace information on some webpage yourself you can use something like the following:

http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=SRC680%2Fcwsqueryenhance

where 'cwsqueryenhance' is the name of the ChildWorkspace and 'SRC680' is the MasterWorkspace it was created on without milestone information. The general formular for such URLs is

http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=<MasterWorkspace>%2F<ChildWorkspace>

Such links and also the features on the QA issuelinks page and the Specification Checking Tool can be used without logon. The SOAP interface of EIS is at https://eis.services.openoffice.org/soap/servlet/rpcrouter. The CWS commandline tools authenticate there using CVS username and crypted CVS password. This must be configured in a .cwsrc file, details about this .cwsrc file can be found on the CWS Wiki entry. The SOAP interface is currently not yet documented, but with CWS.pm there is a perl module for using it available in the OpenOffice.org source code.

Tips & Tricks

• You can change the menu to being displayed at the left side instead of on top via using the Settings link in the right corner and than using the Menu-Style radio buttons on the "Frames" tab page.
• If you are a member of QA and you want to find ChildWorkspaces which do not yet have a QA representative use the "ChildWorkspaces / Seek QA" menu entry.
• to find out what the latest milestone on a given MasterWorkspace is you can either look at EIS (Environment Information System) using the menu entry "MasterWorkspaces / MasterWorkspace Info" or use the command "cwsquery latest".

Contact

EIS is a service operated by Sun and currently maintained by Bernd Eilers. Bernd can often be found on the #OpenOffice.org IRC channel on irc.freenode.net with the nickname rfc821. If you have found a bug in EIS or a feature request for it you can submit an issue in issuezilla under Category tools and with target DevTools to him.

related Links

• ChildWorkspace Policies
• CWS commandline tools documentation
• The email which introduced CWS commandline tools
• TX 20 Report - A document provided by Eric Bachard including amongst other things some very good stuff about EIS and ChildWorkspace handling, eg. Screenshots of the EIS web-frontend, an explanation about ChildWorkspace statuses and an example of typical CWS commandline tool usage for developers.