Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. A user (anyone) creates an Issue (please see #Create Issue Detailed Instructionsfirst)
    • Issue is automatically assigned to a Awaiting Review status
  2. CLE Sakai Core team member verifies the issue for accuracy (i.e. is it an actual issue) and completeness of details.
    • Complete and valid issues are set to status Open and assigned to a user or group (e.g. Samigo Team or CLE Sakai Core Team) who can resolve it.
    • The team member may resolve the issue as Duplicate , Incomplete , or Cannot Reproduce if appropriate (see #Resolution).
  3. Assignee selects Start Progressand begins to work on the issue (as time and priorities allow)
    • Assignee selects Stop Progress if they are not going to work on the issue anymore for a few days and it is not resolved
  4. Assignee sets the issue to Resolved with the relevant #Resolutionwhen work is completed
    • For tasks, if there is nothing explicit for the QA team to test, then the issue is Closed without testing.
  5. QA team selects Start QAand begins verifying the issue
    • QA team member selects Stop QA if they are not going to complete the testing on the issue within a short time frame
  6. QA team verifies resolution of the issue and adds a comment with details of the testing results and process.
    • If verification fails, then it is Reopened for further work (automatically re-assigned to the user who resolved it)
    • If verification succeeds then QA marks the status as Verified (indicating it has been Tested)
  7. Release Manager merges the issue (if it is a bug) to previous supported and affected releases 
    • The associated version merge status is set to Resolved   (see  #MergeStatus )
    • The issue is Closed by the Release Manager when the last merge has been completed

Diagram

(Exported from JIRA Sakai CLE Workflow Sakai Workflow on 31 March 2012 - AZ)

Details

...

  • (Awaiting Review)
    • Contributed patches should receive priority treatment.
    • The issue should be linked to other related issues.
    • Check the is assigned to a user or group (e.g. Samigo Team or CLE Sakai Core Team) who can resolve it.
    • Adjust the Priority depending on overall project and release goals
    • Other attributes should be changed as needed, ( Components , Affects Version , Security Level , Original Estimate , etc.)
  • (Open)
    1. Open tickets should be worked on within 90 days or assigned back to Unassigned
    2. Open tickets which have seen no activity in 180 days will be moved back to Awaiting Review status
  • (Resolved) - General
    1. Resolved tickets which have had no activity in 180 days will be Closed without testing
    2. Details in #Resolution
  • (Tested) QA is complete on this ticket.
  • (Closed) No other activity should or will happen on this ticket

...

  • Alpha, Beta, and RC tags (e.g., alpha03, beta02, RC01) - After a release is made, the interim alpha, beta, and release candidate versions are merged into the released version. For example, 2.6.0-alpha01, 2.6.0-alpha02, 2.6.0-beta01, 2.6.0-rc01, etc. would be merged into 2.6.0. The merging is necessary for keeping it simple to search, filter, and view issues for released versions of Sakai; however, the original version numbers are still associated with each issue in the database, if there is a need to extract such information later on.
  • Maintenance Branch versions as Affects Versions (e.g., 2.3.x, 2.4.x)  You should generally avoid using maintenance branch version as an Affects Version, unless you are sure an issue does not affect past releases on that branch. This is important because branch versions are moving targets; what affects 2.5.x one day will not necessarily affect it in the future, after the issue is fixed.
  • Maintenance Branch versions as Fix Versions (e.g., 2.3.x, 2.4.x) - Generally the only branch version a developer needs to be concerned with is the next major release version for changes they are checking in to trunk. Only the Branch Managers should worry about using maintenance branch versions or beta versions as Fix Versions. They will use maintenance branch versions only when the fix is actually checked-in to the branch. It should not be used as an indication that one would like a fix merged (rather one should set the maintenance branch's status to "Merge".)
  • SAK Experimental Branches (i.e., branch) - Use the generic "branch" version as the Fix Version when working on subtasks under a SAK Experimental Branch. If and when the branch is merged into trunk, please remember to update the Fix Version appropriately (generally this will mean changing it to the next major release at the time the branch is merged to trunk.)
  • Developers- Can only use actual release version where the fix is made as the Fix Version and indicate it should be merged using the special "Merge" fields (as discussed in the CLE Sakai Core team).
    • For instance if the fix is made in trunk, and trunk is 2.10-SNAPSHOT the fix version should only be set to 2.10 [tentative]
  • Branch Managers - Can use any version which is appropriate including beta or alpha versions (which are indicators of when something was merged and what it was merged into).

...