Pavel's diary

TIP: Using EIS (Environment Information System)

I have decided (well, Michael decided that I should be punished for not reading the source code of tools I use ;-) to extend my previous small tip about child workspaces in EIS to a complete user-level documentation of EIS.

Environment Information System (EIS for short, http://eis.services.openoffice.org/) is a system that provides valuable informations for OpenOffice.org' developers.

You can access it in two modes - as a guest user with read-only privileges or as an openoffice.org' registered user. I'll describe only access for registered users because guest user access is a subset of it.

To access EIS as a registered user, you have to log in: Use your OpenOffice.org' e-mail address as a Username.

If you login successfully, you'll see your OpenOffice.org' username at the right side of the GUI.

The most important part of the GUI is Child workspaces link: After clicking on it, new submenu is opened. Its entries are described in details below.

My CWSs allows the developer to track his own child workspaces. Clicking on it, you'll see the list of your opened child workspaces in a simple table with complete informations about them: You can also see the status of your child workspaces there (see below for possible states). The names of child workspaces are links to more detailed information about the corresponding child workspace (status history, tasks assigned to this child workspace, modules and other valuable facts): Child workspace can be in one of the following states: planned, new, ready for QA, nominated, integrated or deleted. When you create it using the below mentioned link in EIS, its initial state is planned. When you finally create it using the cwscreate command, it is promoted to new level. If you want to discard it, you change its state to deleted. After your planned changes are finished, you assign it to QA and promote the status to ready for QA. QA person then can change the status back to new (if there are problems) or nominate it for inclusion. After the integration of your child workspace, the status is changed to integrated.

Browse allows you to browse in the list of all child workspaces. As you can see in the image, you can browse the list by the master workspaces (like SRC680, SRX645, ...) and their state.

Another useful tool is Search. I personally found it as the most valuable piece of EIS. You can search child workspaces (TIP: use pj% to find all child workspaces whose names start with letters pj), IssueZilla' tasks etc.

Milestones is very useful if you need to know what was integrated into the milestones. E.g. the following picture shows child workspaces integrated into m62: Releases is very useful if you need to know what was integrated into the release - you have to choose the release in the left panel and the list will be displayed on the right side. In the Create menu, you can create child workspace (it will be in "planned" state until you promote it to new by using cwscreate tool). The name field is the name of the child workspace to be created. Please use descriptive name if it implements a new feature and add e.g. 01 to its name (e.g. writerperfect01, ihateword01 etc.). If it is simple bugfix child workspace, the common standard is to have your id/nick/username appended by the uniq number, like ause01, pj12 etc.

In the field Master Workspace you have to chose the master workspace of your child workspace. Only SRC680 and SRX645 makes sense. So if you plan to work on 2.0 issues, you have to choose SRC680.

You can't change the status of your child workspace while creating, because it will always be created in the state "planned". But later on, you can use the Status select box to change the status of your child workspace.

FIXME: filling QA representative.

The field Members is to be filed with people who are interested in this child workspace. They are then informed about states changes etc.

The Description field is self-descriptive. Please enter the complete description here. It should help people who do not find the child workspace itself descriptive enough.

QA comment is something like a chat between you, QA people and others. Enter useful information only and keep it short though.

To allow some planning, you must also fill in some dates like Estimated due date (ready for QA) and Estimated due date. The first one is your estimation on when it will be ready for QA work. If the date is slipped and your child workspace is not in the status of "ready for QA" you'll receive an e-mail notice about that. Use ISO format for dates (like 2004-11-17 for today). Or press the bubble help icon and read what it tells you ;-)

Level of impact helps people distinguish which applications could be impacted by the integration of this child workspace. For simple build fixes, use "Implementation Details Only".

If your child workspace creates new dialog or changes already existing UI, please check the UI-relevant checkbox. The same applies to Help-relevant. -----