THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
When you create a JIRA it needs to have an Issue Type. This is important because it helps to classify the issue and can be one of the following type:
| Issue Type | Definition and when to use this type | ||
|---|---|---|---|
| Bug | A bug is generally a problem with code or data which is not functioning correctly. | ||
| Improvement | An improvement is something that enhances the functionality of an existing feature | ||
| New Feature | New functionality that does not already exist (What is the difference between this and Wish?)
|
The proposal seems inline with the existing text regarding creating JIRA This following text comes from our existing pages re Jira : If you don't have a patch, and you have want to suggest an enhancement or new feature, then discuss this in the dev mailing list instead of creating a Jira issue; at the end of the discussion, the community will consider if a summary of the thread should be saved in a new Jira issue, to facilitate future development | |||
| Task | A Task is an action that needs to be carried out that does not fall under any of the other issue types. (NOTE: We have used Tasks in the past - maybe need to specify more clearly when to use....) | ||
| Test | A Test is a unit test or integrated test | ||
| Wish | A Wish is a requirement for new something that does not already exist (What's the difference between this and New Feature?
|
The proposal seems inline with the existing text regarding creating JIRA This following text comes from our existing pages re Jira : If you don't have a patch, and you have want to suggest an enhancement or new feature, then discuss this in the dev mailing list instead of creating a Jira issue; at the end of the discussion, the community will consider if a summary of the thread should be saved in a new Jira issue, to facilitate future development |
| Sub Task | This task is a child of another JIRA:
|
Summary
This is a brief title for the issue and summarises what the issue is about. It must give us the key information. Try to focus on the actual issue that you are facing as this will help us quickly identify and classify it.
...
- Create a separate SVN repository for OFBiz official plugins
- Add the auto-entity CRUD services for Runtimedata
- View Sales Order throws exception in getReturnableQuantity
- Not able to select virtual products in WebPos
| Info |
|---|
Proposal:
|
...
- OFBiz has several versions of the code base available as released and unreleased branches, as well as the trunk and JIRA covers all of them.
- Blocking and Critical issues are generally reserved for problems with production systems (i.e systems that customers use).
- The OFBiz 'production systems' are our officially released versions that have been signed and approved for release and issues here are the highest priority.
| Priority | Current JIRA Definition | Proposed Revised Definition and when to to use this priority | ||
|---|---|---|---|---|
| Blocker | Blocks development and/or testing work, production could not run | A blocking issue an issue with a released OFBiz version that does not run, causes the system to crash, is security vulnerability to users or exposes the project and Apache Software Foundation to significant risk | ||
| Critical | Crashes,loss of data, severe memory leak | A critical issue is an issue with a released OFBiz version that causes the system to crash, become unstable, lose data and has no workaround. | ||
| Major | Major loss of function | A major issue is an issue with a released OFBiz version that has a significant impact due to loss of function and has no or limited workarounds
| ||
| Minor | Minor loss of function or problem where easy workaround is present | A minor issue is an issue with a released OFBiz version, an unreleased branch or trunk that has isolated impact but workarounds are available | ||
| Trivial | Cosmetic problem like misspelt words or misaligned text | A trivial issue is an issue with a released OFBiz version, an unreleased branch or trunk that are cosmetic or do not change the functionality |
Labels
Labels are a way to classify issues.
...
Also be aware that the JIRA labels are shared across all ASF JIRA projects so you will find labels releated to other projects in the drop down selection box.
| Info |
|---|
Proposal
|
...
Clean up all existing open issues by removing any non standard labels and assign issue to the appropriate component
| Standard List | Keep - yes / no | Comments |
|---|---|---|
| agreements | yes |
| budget | yes |
| calendar | yes | This is part of the workeffort but a specific implementation of it |
| currency | yes |
| database | yes |
| dropship | yes |
| finAccount | yes | Maybe write in full - financial account |
| ftl | yes | Or make it more obvious - and say freemarker |
| groovy | yes |
| i18n | yes |
| invoice | yes |
| locale | yes |
| newbie | yes | we could also call it beginner... |
| payment | yes | Would be better if this was called payments |
| refactoring | yes |
| reporting | yes |
| shipment | yes |
| survey | yes |
| tax | yes |
| tenant | yes | Need to decide if we call it tenant or multi-tenant, we don't need both |
| tomcat | yes |
| vat | yes | It could be under tax, but VAT does has some specific rules so separating it out from generic tax could be useful for the community |
Reporter
The issue 'Reporter' is the person that creates the issue. This is automatically assigned by JIRA based on the user profile of the person creating the Jira.
Assignee
The 'Assignee' is the person that is currently working on the JIRA issue. By default when an issue is created, the assignee is blank.
...
The following is a list of the existing JIRA components for OFBiz with their current Component Leads.
| Component | Component Lead | Component Description | Needs to be Updated and/or Removed |
|---|---|---|---|
| accounting |
ALL APPLICATIONS |
ALL COMPONENTS |
Attic |
base |
BuildBot |
commonext |
Confluence |
content |
datamodel |
Demo |
framework |
commonext
Confluence
content
datamodel
Demo
framework
framework/webtools
Gradle
humanres
manufacturing
marketing
order
| David E Jones | |||
framework/webtools | |||
Gradle | |||
humanres | |||
manufacturing | |||
marketing | |||
order |
party | Nicolas Malin |
POS |
product |
securityext |
site |
specialpurpose/appserver |
specialpurpose/assetmaint |
specialpurpose/bi |
specialpurpose/ |
birt | |||
specialpurpose/cmssite |
specialpurpose/ebay |
specialpurpose/ebaystore |
specialpurpose/ecommerce |
specialpurpose/example |
specialpurpose/exampleext |
specialpurpose/googlebase |
specialpurpose/googleCheckout |
specialpurpose/hhfacility |
specialpurpose/ldap |
specialpurpose/lucene |
specialpurpose/myportal | Hans Bakker |
specialpurpose/oagis |
specialpurpose/passport |
specialpurpose/pos | Jacques Le |
| Roux | ||
specialpurpose/projectmgr | Hans Bakker |
specialpurpose/scrum | Hans Bakker |
specialpurpose/solr |
specialpurpose/webpos |
start |
themes |
| tools |
| tools/security | Jacques Le Roux |
| workeffort |
Flags
There are two flags available on a JIRA issue. One flags that the issue is a Patch and the other that the issue is Important.
...
The status field tracks the current status of an issue from creation to resolution or closure.
| Status | Definition |
|---|---|
| Open | This status indicates that the issue is open and is the default status when a JIRA issue is created |
| In Progress | This status indicates that the issue is in progress and that someone is working on it |
| Reopened | This status indicates that the issue has been previously closed but has to be re-opened because of some additional work |
| Resolved | This status indicates that the issue has been resolved. If the issue is code or patch related then it also indicates that the code has been committed |
| Closed | This status indicates that the issue has been closed. It can indicate issue completion or simply the closure of an invalid issue |
| Patch Available | This status indicates that the issue has a code patch uploaded that will resolve the issue. |
Affect Versions
Fix Versions
...
- If you have discovered a bug that has not yet been reported
- If you have identified a bug then also fixed it and want to contribute the fix back to the project, then you can create an issue and attach your patch to it. (Note if the issue has already been created then attach your patch to the existing issue and do not create a jira)
- If after a community mailing list discussion the recommendation is the create a JIra (e.g. new features, improvements etc)
Discussion Point :
if, on the other hand, you don't have time to do this, (i.e. to discuss the design solution with the community) you have already decided that you want to implement your patch following your design notes, and you just want to let the community know about the upcoming patch, you can create a Jira issue (to which you will attach your patch when it is ready
- Doing this means that patches for improvements and new features can get uploaded to JIRA and the community has not discussed or agreed they want them or are necessary
- Are we trying to use JIRA like a patch code repository too? If so then is JIRA the best place to do it? How do we make the distinction between patches that are contributed and are accepted to the repository and those that are not acceptable due to whatever reasons (coding, design etc)
...
How to Create a JIRA Issue
- You need a JIRA account so if you do not have one then create an account here
- Login to your JIRA account
- Click 'Create' at the top of the screen to create a new issue and a screen form will be displayed for you to fill in
- Project: OFBiz should the default project for the issue. If it is not then please select it from the dropdown selection box
- Issue Type: Bug is the default so please change this if your issue belongs to a different issue type
- Priority: Major is the default priority. Please review the guidelines around assigning a priority and change it if necessary
- Component: Select the OFBiz component that is affected by the issue you are creating. If all components are affected select ALL_COMPONENTS
- Affect version: Select the OFBiz version that is affected by the issue you are creating. I
- Assignee: If you are going to work on this issue yourself the enter your name
- Reporter: The name of the person creating the issue should be automatically default as the reporter
- Environment: Specify at least your operating system and the database you are using for OFBiz as this information could be very useful to help people working on the issue. If you are running the trunk then please specify the SVN revision number
- Description:
...
- If you need to attach files such as patches you must do it as a second step after the issue creation. It is also possible to easily attach screenshots to the issue see here
- When attaching files or screenshots you can add a comment where you explain how the attached file is supposed to be used. Please reference the file name in the comment because more files could be attached to the issue at a later time and they will be all listed togheter far from their comments. If, for any reason, you don't want your patch or attachment to be granted to the ASF or committed, please note it in one related comment (possible cases: not ready yet, examples, etc.)
- Also please use preferably .patch as extension for patches. When updating an attached file keep the same name : Jira is able to deal with that and will simply gray old files, you don't need to delete them (sometimes its usefull to compare older patches versions)
- If you provide a patch, be sure to use the button "Provide Patch" (the status will then be "Patch Available"). This allows us (commiters) to know that this issue is ready for review.
- Jira offers a voting mechanism that is used to give more relevance to the issues (see here to learn more)
...
- Create an account here, if you do not have one
- Login
- (optional if you are sure it's new) Search if an issue for what you are after already exists by using the "Find issues"
- (optional if you are sure it's new) If an issue on the subject already exists you can add a comment on it
- If a issue does not exist, create a new one selecting the "create new issue" command. For details on the issue creation see here
- Select the OFBiz project and the issue type.
- Fill in all fields, give as many detail you think necessary
- Generally it is very important to select in the "Affect version" field the ofbiz version you are running. If you are running the trunk then the SVN revision should also be specifyed in the Environment field
- Use the Environment field to specify at least your operating system and the database ofbiz is using since these information could be very useful to help people to work on the issue
- Select the concerned component(s). If all components are affected select ALL_COMPONENTS (uncommon case)
- If you need to attach files such as patches you must do it as a second step after the issue creation. It is also possible to easily attach screenshots to the issue see here
- When attaching files or screenshots you can add a comment where you explain how the attached file is supposed to be used. Please reference the file name in the comment because more files could be attached to the issue at a later time and they will be all listed togheter far from their comments. If, for any reason, you don't want your patch or attachment to be granted to the ASF or committed, please note it in one related comment (possible cases: not ready yet, examples, etc.)
- Also please use preferably .patch as extension for patches. When updating an attached file keep the same name : Jira is able to deal with that and will simply gray old files, you don't need to delete them (sometimes its usefull to compare older patches versions)
- If you provide a patch, be sure to use the button "Provide Patch" (the status will then be "Patch Available"). This allows us (commiters) to know that this issue is ready for review.
- Jira offers a voting mechanism that is used to give more relevance to the issues (see here to learn more)
If you don't have a patch, and you have discovered a bug, create a Jira issue (if there is not one already) providing as much details as possible (including the rev. number and the environment you are using, and the step to recreate the bug). if you have no ideas how to describe the bug use this template
...
Add a wiki page (if one does not exist) documenting:
- Guidelines for writing JIRA mentioning clarity, provision of solution.
- A clear definition of priorities (blocker, critical, major, minor,
trivial) with some examples.
- A description of meaning of assignee and how to use it
- A description of other metadata and how to properly use it (tags,
components, affects version, etc...)
TO TIDY UP - Copied from Committers Roles and Responsibilities page
Type of changes and where should they go
There are roughly 3 main types of changes:
- New features
- Improvements
- Bug fixes
Bug fixes should normally go in the release branches, as much as they can. Security fixes must trigger a new released packages.
New features and Improvements should never get into a release branch. Exceptions may occur, but they need a consensus, and as ever can be vetoed (only by committers, though this rule can be adapted by the community)
All committers must do the following to ensure licensing compliance
- Make sure the contribution is posted publicly on the Apache OFBIZ JIRA issue tracker. Please do not commit changes that were sent to you privately. If you receive a patch, open a JIRA issue and then ask the submitter to post his patch there. This way, we can avoid having to get an iCLA for the contributor, as well as let everybody in the community view and comment on the contribution.
- If it is a new file, the file must have the Apache 2.0 license header.
- The commit log must identify the name of the contributor and, if relevant, the JIRA issue for it.
Manage JIRA's issues
Please take the time to correctly fill the different Jira fields we now use for our releases change logs.
- Specifiy in Resolution :
- Improvements : use either Done or Implemented Status as you feel right
- New features : use the Implemented Status
- Bug : use the Fixed Status
- Of course you might also use other status (like duplicate, won't fix, invalid, etc.) when needed...
- Specify in the Fix Version/s the codebase(s) to which you have committed the patch/fix :
Temporary warning
Because we decided to not release the R14.12 and R15.12 branches, and because 13.07.03 was the last release of the R13.07 branch, currently only "Upcoming Branch" and Release Branches (like Release Branch 15.12) are available in the "Fix Version/s" field. Not released versions (like 13.07.03) will no longer appear but when we wil release the next coming R16 branch.
- you can select from the dropdown one or more of the items under the "Unreleased Versions" group in the top part of the drop down box;
- you should never use one of the items in the "Released Versions" section (bottom part);
- if the commit is only done (ie not backported) on "Trunk" then select "Upcoming Branch";
- if you are backporting/committing to a release branch then select the latest (next) release version in that branch available in the dropdown.
After some time the following Jira reports will contain very useful information :
- Road Map (what is expected in upcoming releases) : https://issues.apache.org/jira/browse/OFBIZ/?selectedTab=com.atlassian.jira.jira-projects-plugin:roadmap-panel
Change Log (what is available in released packages available from the Download page) : https://issues.apache.org/jira/browse/OFBIZ/?selectedTab=com.atlassian.jira.jira-projects-plugin:changelog-panel
- Note about backports for bug fixes
When you don't backport a bug fix to a release branch, please explain the reason/s you don't backport. Then when others review they don't wonder why it was not backported and don't have to search why!
TO TIDY UP - Copied from Contributors Best Practices Page
How to create a Jira issue
- Create an account here, if you do not have one
- Login
- (optional if you are sure it's new) Search if an issue for what you are after already exists by using the "Find issues"
- (optional if you are sure it's new) If an issue on the subject already exists you can add a comment on it
- If a issue does not exist, create a new one selecting the "create new issue" command. For details on the issue creation see here
- Select the OFBiz project and the issue type.
- Fill in all fields, give as many detail you think necessary
- Generally it is very important to select in the "Affect version" field the ofbiz version you are running. If you are running the trunk then the SVN revision should also be specifyed in the Environment field
- Use the Environment field to specify at least your operating system and the database ofbiz is using since these information could be very useful to help people to work on the issue
- Select the concerned component(s). If all components are affected select ALL_COMPONENTS (uncommon case)
- If you need to attach files such as patches you must do it as a second step after the issue creation. It is also possible to easily attach screenshots to the issue see here
- When attaching files or screenshots you can add a comment where you explain how the attached file is supposed to be used. Please reference the file name in the comment because more files could be attached to the issue at a later time and they will be all listed togheter far from their comments. If, for any reason, you don't want your patch or attachment to be granted to the ASF or committed, please note it in one related comment (possible cases: not ready yet, examples, etc.)
- Also please use preferably .patch as extension for patches. When updating an attached file keep the same name : Jira is able to deal with that and will simply gray old files, you don't need to delete them (sometimes its usefull to compare older patches versions)
- If you provide a patch, be sure to use the button "Provide Patch" (the status will then be "Patch Available"). This allows us (commiters) to know that this issue is ready for review.
- Jira offers a voting mechanism that is used to give more relevance to the issues (see here to learn more)
When to create a Jira issue
- Before creating any Jira issue, please check, using some related key words, if a similar issue does not exist already. For that you can first use the quich search at top right of Jira pages and after refine your search using relevant information. For instance by default all projects are scanned, you may then search only in OFBiz, etc.
- If you already have a patch for an improvement/fix then create a Jira issue (if there is not one already) and attach your patch to it
- If you don't have a patch, and you have discovered a bug, create a Jira issue (if there is not one already) providing as much details as possible (including the rev. number and the environment you are using, and the step to recreate the bug). if you have no ideas how to describe the bug use this template
- What you did (including detailed steps to reproduce)
- What you expected to happen
- What actually happened (including exact quotes of error messages, etc)
- If possible provide an URL
- If you don't have a patch, and you have want to suggest an enhancement or new feature, then discuss this in the dev mailing list instead of creating a Jira issue; at the end of the discussion, the community will consider if a summary of the thread should be saved in a new Jira issue, to facilitate future development
- If you don't have a patch, but you are planning to work on it, and you want to share your design details with the community, you should discuss this in the mailing list instead of creating a Jira issue; if, on the other hand, you don't have time to do this, you have already decided that you want to implement your patch following your design notes, and you just want to let the community know about the upcoming patch, you can create a Jira issue (to which you will attach your patch when it is ready);
Summarizing:
- Bugs: always create a new Jira issue everytime you find a new bug
- New features/enhancements: create new Jira issue only if you have a patch (or if you plan to submit it very soon)
Editing comments in Jira
This feature should be used very parsimoniously because it's not easy to read edited comments from a mailing list and most people read comments from the dev ML (Jira issues are redirected to dev ML).
So, as far as it's possible, you should better add a new comment than editing one. If you really need to edit a comment, you MUST put a BIG prefix before your comment so it is possible to distinguish it from the original text. That should include more than just a pair of "*" to bold part or all of the response, and should also include your initials so that it is clear which things you added.
- Before creating any Jira issue, please check, using some related key words, if a similar issue does not exist already. For that you can first use the quich search at top right of Jira pages and after refine your search using relevant information. For instance by default all projects are scanned, you may then search only in OFBiz, etc.i