Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Papyrus/Papyrus Developer Guide/How To- Plan contribution"
(→How to contribute to the release plan) |
(→= Flag) |
||
Line 8: | Line 8: | ||
The keyword 'plan' should be set in the keyword field | The keyword 'plan' should be set in the keyword field | ||
− | == Flag = | + | == Flag == |
The bug shall have the flag 'Mars' with '+' set. | The bug shall have the flag 'Mars' with '+' set. | ||
Revision as of 09:29, 8 December 2014
Contents
How to contribute to the release plan
Release plan is contributed through bugzilla. It is relying on a given set of queries over the bugzilla base. All items that should be part of the roadmap have to follow the following rules in order to be present in the roadmap plan.
Component
The bugs should be recorded against the MDT.Papyrus component.
Keyword
The keyword 'plan' should be set in the keyword field
Flag
The bug shall have the flag 'Mars' with '+' set.
Whiteboard
The bugs to build the roadmap are classified against a predefined set of themes. For the Mars version of Papyrus, the following themes are available
Themes | |
---|---|
Whiteboard | Description |
Editors | All generic features related any kind of Papyrus diagram editor |
Extensibility | Extensiblity improvements of the MDT Papyrus implementation and APIs |
Scalability | Scalability and performance improvements of the Papyrus implementation and APIs |
Usability | usability improvements of the Papyrus implementation and APIs |
Documentation | Documentation of the Papyrus implementation and APIs, user & developer aspects |
Miscellaneous | Tasks that may not be included in one of the previous theme |
Eclipse_Compatibility | Support and compatibility with platform 4.X and 3.X |
Version and Milestone
- The target version should be set to the incoming release version, for example 1.1.0 for the Mars version of Papyrus
- The target milestone is the expected milestone in which the feature will be published as a feature of the tool, and publicly available from the milestone downaload site.
- For example, for a new feature expected to be in version 1.1 M4, set to 'M4'
- If the feature is not sure to be in the release, for example, if it is not sure that committers will have time to work on that item, the target milestone should be set at 1.1.0. As soon as a committer can work on it, he will update the bug to set the target milestone.
- If the feature is deferred, because of lack of time or impossibility to develop, the flag has to be set at '-'. It will indicates that the feature won't be developed in this flagged version