Difference between revisions of "EIS"
| Line 1: | Line 1: | ||
[[Category:Quality Assurance]][[Category: Development]][[Category: Specification]] | [[Category:Quality Assurance]][[Category: Development]][[Category: Specification]] | ||
| − | [http://eis.services.openoffice.org EIS (Environment Information System)] consists of a database keeping information about MasterWorkspaces and [[CWS | ChildWorkspaces (short CWS)]] as well as some additional things | + | [http://eis.services.openoffice.org EIS (Environment Information System)] consists of a database keeping information about MasterWorkspaces (short MWS) and [[CWS | ChildWorkspaces (short CWS)]] as well as some additional things, a web-frontend used by everyone involved with work on [[CWS | ChildWorkspaces]] ( eg. [http://development.openoffice.org/ developer], [http://qa.openoffice.org/ QA] member, [http://documentation.openoffice.org/ Documentation] writer, member of [[User_Experience_Community | User Experience Team]], those working on [http://l10n.openoffice.org/#l10n localization] and [http://l10n.openoffice.org/#i18n internationalization] etc. ) and a [http://en.wikipedia.org/wiki/SOAP SOAP] interface used by a bunch of [http://tools.openoffice.org/dev_docs/ooo-cws-tools-doc.sxw commandline tools] which are used by developers to create and maintain [[CWS | ChildWorkspaces]]. |
| − | + | You can log into the web frontend at [http://eis.services.openoffice.org http://eis.services.openoffice.org] with you OOo email address (including @openoffice.org) and your OOo password. A read-only anonymous access is also available there. | |
| − | [http://eis.services.openoffice.org EIS] is also needed if you want to write feature mails to inform developers, Quality Assurance (QA) engineers, localization- (L10N) and documentation-people about changes in the office code. | + | [http://eis.services.openoffice.org EIS] is also needed if you want to write [http://eis.services.openoffice.org/EIS2/servlet/changesmails.ShowFeatureMails feature mails] or [http://eis.services.openoffice.org/EIS2/servlet/changesmails.ShowAPIChangesMails api changes] to inform developers, Quality Assurance (QA) engineers, localization- (L10N) and documentation-people about changes in the office code. |
| + | |||
| + | Additionally [http://eis.services.openoffice.org EIS] provides a few [http://en.wikipedia.org/wiki/RSS_(file_format) RSS feeds] with information about [[CWS | ChildWorkspaces]] and MasterWorkspaces. The [http://eis.services.openoffice.org/EIS2/cws.rss.CWSAnnounceNewsFeed/mws feed that informs about new milestones on MasterWorkspaces] for example is [http://en.wikipedia.org/wiki/Web_syndication syndicated] on [http://go-oo.org/planet Planet OpenOffice.org]. | ||
| + | |||
| + | Development on OpenOffice.org/StarOffice is using [http://tools.openoffice.org/dev_docs/OOo_cws.html branches] in the source code repository (currently [http://en.wikipedia.org/wiki/Concurrent_Versions_System CVS]) a set of [http://tools.openoffice.org/dev_docs/ooo-cws-tools-doc.sxw commandline tools] and the tool called | ||
| + | [http://eis.services.openoffice.org EIS]. [http://eis.services.openoffice.org EIS] is the acronym for Environment Information System and also the german word for the english word ice bye the way. The basic idea here is that there exists so called MasterWorkspaces (short MWS) which are used for the production version and [[CWS | ChildWorkspaces (short CWS)]] which are used to work on new features and/or bugfixing. [http://development.openoffice.org/releases/index.html 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 [[CWS | 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 [http://eis.services.openoffice.org/EIS2/cws.MilestoneData milestones] on the master workspace (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 | ||
| + | |||
| + | [[CWS | ChildWorkspaces]] in [http://eis.services.openoffice.org EIS] do have a status which reflects what is currently being done on the [[CWS | ChildWorkspace]]and if the [[CWS]]has already gone into production code or the [[CWS]] is still being worked on. | ||
| + | |||
| + | List of statuses know to [http://eis.services.openoffice.org EIS]: | ||
| + | # 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. | ||
| + | # new: [[CWS]] with this state have been created, they do have a physical representation somewhere and development is currently working on it. | ||
| + | # 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 handling for the MasterWorkspace is configured QA can now set the state to nominated or approved by QA if QA accepts the changes on the [[CWS | ChildWorkspace]]or set the state back to new if the [[CWS]] ist rejected. | ||
| + | # approved by QA: This is a special intermediate state used when a more controlled approach is active for the MasterWorkspace the [[CWS]] was created. In this case QA approves a [[CWS]] but program management has the finaly say if and when something goes into the master. That is program management can than set the state nominated. | ||
| + | # nominated: The [[CWS]] has been handed over to Release Engineering which can now start to integrate the [[CWS]] into the MasterWorkspace | ||
| + | # integrated: all work on the [[CWS]] is finished and the changes on the [[CWS | ChildWorkspace]] have been integrated into the MasterWorkspace. | ||
| + | # canceled: A canceled [[CWS]] has been abandoned, no more work will be done on it. This state is state for [[CWS]] which where once in state new but are not needed anymore. | ||
| + | # deleted: similar to canceled this is for [[CWS]] which are not needed any more. The difference is that deleted can only be set for planned [[CWS]] which never made it to being actually physically created and state new. | ||
| + | # fixed on master: this is used to reflect changes done by Release Engineering directly on the Master usually to fix a very special urgent problem or conflict in EIS. [[CWS]] in this state are not really existing physically these are just entries in EIS to reflect changes done directly on the MasterWorkspace branch. | ||
| + | # finished: This is a special state used for Special-Product-Release [[CWS | 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 which will never get into the MasterWorkspace. | ||
| + | # pre-nominated for PP: a historic state used for special Product Patch [[CWS]] handling, no longer used. | ||
| + | # 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. | ||
| + | |||
| + | There is a set of [http://tools.openoffice.org/dev_docs/child_workspace_policies.html ChildWorkspace Policies] which regulates how work on a [[CWS | ChildWorkspace]]is done eg. how issues in OpenOffice.org's bugtracking system issuezilla are usually assigned to [[CWS | ChildWorkspaces]] and how the different kinds of people involved in the lifecycle of a [[CWS | ChildWorkspace]] interact with each other. [http://eis.services.openoffice.org EIS] knows about two different kinds of [[CWS | 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 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 [http://eis.services.openoffice.org EIS] web-frontend which does show this information. Most [[CWS | 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 [[CWS | ChildWorkspaces]]. | ||
| + | [[CWS | ChildWorkspaces]] always have an "Owner" and a "QA representative" which usually should be two distinct persons ;-). Other types of information kept in [http://eis.services.openoffice.org 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. [http://eis.services.openoffice.org EIS] also offers some statistics about [[CWS | ChildWorkspaces]]. | ||
Revision as of 17:10, 31 October 2006
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 you 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.
Additionally EIS provides a few RSS feeds with information about ChildWorkspaces and MasterWorkspaces. The feed that informs about new milestones on MasterWorkspaces for example is syndicated on Planet OpenOffice.org.
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 basic idea here is that there exists so called MasterWorkspaces (short MWS) which are used for the production version and ChildWorkspaces (short CWS) which are used to work on new features and/or bugfixing. 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 master workspace (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 ChildWorkspaceand if the CWShas already gone into production code or the CWS is still being worked on.
List of statuses know to EIS:
- 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.
- new: CWS with this state have been created, they do have a physical representation somewhere and development is currently working on it.
- 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 handling for the MasterWorkspace is configured QA can now set the state to nominated or approved by QA if QA accepts the changes on the ChildWorkspaceor set the state back to new if the CWS ist rejected.
- approved by QA: This is a special intermediate state used when a more controlled approach is active for the MasterWorkspace the CWS was created. In this case QA approves a CWS but program management has the finaly say if and when something goes into the master. That is program management can than set the state nominated.
- nominated: The CWS has been handed over to Release Engineering which can now start to integrate the CWS into the MasterWorkspace
- integrated: all work on the CWS is finished and the changes on the ChildWorkspace have been integrated into the MasterWorkspace.
- canceled: A canceled CWS has been abandoned, no more work will be done on it. This state is state for CWS which where once in state new but are not needed anymore.
- deleted: similar to canceled this is for CWS which are not needed any more. The difference is that deleted can only be set for planned CWS which never made it to being actually physically created and state new.
- fixed on master: this is used to reflect changes done by Release Engineering directly on the Master usually to fix a very special urgent problem or conflict in EIS. CWS in this state are not really existing physically these are just entries in EIS to reflect changes done directly on the MasterWorkspace branch.
- 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 which will never get into the MasterWorkspace.
- pre-nominated for PP: a historic state used for special Product Patch CWS handling, no longer used.
- 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.
There is a set of ChildWorkspace Policies which regulates how work on a ChildWorkspaceis 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 CWSand 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.
