Recent changes to Development Process

Development Process modified by Anders Widell

Anders Widell — Tue, 11 Apr 2017 11:37:54 -0000

--- v14
+++ v15
@@ -1,4 +1,4 @@
-Note: this page will soon be updated to reflect the new workflow when using [GIT].
+Note: this page will soon be updated to reflect the new workflow when using [GIT] and the new [branching strategy](https://sourceforge.net/projects/opensaf/files/docs/OpenSAF%20Branching%20and%20Release%20Strategy%20170315.pdf/download).

 Writing a ticket
 ------------------

Development Process modified by Anders Widell

Anders Widell — Tue, 11 Apr 2017 11:07:34 -0000

--- v13
+++ v14
@@ -1,3 +1,5 @@
+Note: this page will soon be updated to reflect the new workflow when using [GIT].
+
 Writing a ticket
 ------------------

Development Process modified by Mathi Naickan

Mathi Naickan — Wed, 19 Aug 2015 04:54:45 -0000

--- v12
+++ v13
@@ -15,7 +15,7 @@
 * When working on a **Defect**, set the milestone field to the oldest release where the code will be included. This will help in planning the release and tracking what is included in the different OpenSAF releases. The default value in the milestone field is configured(in the tool) to contain the oldest maintenance release in the pipeline.
 For example:-
 Suppose the two maintenance releases in pipeline are 4.5.x and 4.6.y. Between these two, 4.5.x is the oldest.
-- If the fix for a defect has to be pushed into all of 4.5.x and 4.6.y and default branches, then you should set the milestone to 4.5.x. But, if the fix has to be pushed only to the 4.6.y and default branches, then you should set the milestone to 4.6.y.
+If the fix for a defect has to be pushed into all of 4.5.x and 4.6.y and default branches, then you should set the milestone to 4.5.x. But, if the fix has to be pushed only to the 4.6.y and default branches, then you should set the milestone to 4.6.y.

 * When working on an **Enhancement** ticket, then the fix should only be included in the latest release that is currently under development, i.e. the 'default' branch.  For example, if the next enhancement release is 4.z, then the Milestone shall be set to 4.z.FC where FC stands for "feature complete".
 Also, Defects can be uncovered while testing features that are pushed during an *ongoing enhancements release*, i.e. GA tag is not yet applied on that enhancements branch.

Development Process modified by Mathi Naickan

Mathi Naickan — Fri, 07 Aug 2015 11:35:46 -0000

--- v11
+++ v12
@@ -12,10 +12,10 @@

 **(b)** Set the **Milestone**. 

-* When working on a **Defect**, set the milestone field to the oldest release where the code will be included. This will help in planning the release and tracking what is included in the different OpenSAF releases. The default value in the milestone field is configured to be set to the oldest maintenance release in the pipeline.
+* When working on a **Defect**, set the milestone field to the oldest release where the code will be included. This will help in planning the release and tracking what is included in the different OpenSAF releases. The default value in the milestone field is configured(in the tool) to contain the oldest maintenance release in the pipeline.
 For example:-
-Suppose the two maintenance releases in pipeline are 4.5.x and 4.6.y. Then between these two 4.5.x is the oldest.
-- If the fix for that defect has to be pushed into all of 4.5.x and 4.6.y and default branches, then you should set the milestone to 4.5.x. But, if the fix has to be pushed only to the 4.6.y and default branches, then you should set the milestone to 4.6.y.
+Suppose the two maintenance releases in pipeline are 4.5.x and 4.6.y. Between these two, 4.5.x is the oldest.
+- If the fix for a defect has to be pushed into all of 4.5.x and 4.6.y and default branches, then you should set the milestone to 4.5.x. But, if the fix has to be pushed only to the 4.6.y and default branches, then you should set the milestone to 4.6.y.

 * When working on an **Enhancement** ticket, then the fix should only be included in the latest release that is currently under development, i.e. the 'default' branch.  For example, if the next enhancement release is 4.z, then the Milestone shall be set to 4.z.FC where FC stands for "feature complete".
 Also, Defects can be uncovered while testing features that are pushed during an *ongoing enhancements release*, i.e. GA tag is not yet applied on that enhancements branch.

Development Process modified by Mathi Naickan

Mathi Naickan — Fri, 07 Aug 2015 11:32:11 -0000

--- v10
+++ v11
@@ -6,7 +6,7 @@
 Starting to work on a ticket
 ------------------

-When you 'start' working on a ticket, you the below guidelines need to be followed:
+When you 'start' working on a ticket, the below guidelines are applicable:

 **(a)** The ticket should be accepted - i.e. change the ticket status to **accepted** and set yourself as the owner of the ticket. This way, other people can see what you are working on and we reduce the risk that two people are working on the same task without knowing about it.

Development Process modified by Mathi Naickan

Mathi Naickan — Fri, 07 Aug 2015 11:23:31 -0000

--- v9
+++ v10
@@ -8,9 +8,9 @@

 When you 'start' working on a ticket, you the below guidelines need to be followed:

-(a) The ticket should be accepted - i.e. change the ticket status to **accepted** and set yourself as the owner of the ticket. This way, other people can see what you are working on and we reduce the risk that two people are working on the same task without knowing about it. 
+**(a)** The ticket should be accepted - i.e. change the ticket status to **accepted** and set yourself as the owner of the ticket. This way, other people can see what you are working on and we reduce the risk that two people are working on the same task without knowing about it. 

-(b) Set the **Milestone**. 
+**(b)** Set the **Milestone**. 

 * When working on a **Defect**, set the milestone field to the oldest release where the code will be included. This will help in planning the release and tracking what is included in the different OpenSAF releases. The default value in the milestone field is configured to be set to the oldest maintenance release in the pipeline.
 For example:-
@@ -23,7 +23,7 @@
 - For defects uncovered when testing the 4.z.FC taggged code, the milestone field shall be set to the next milestone which is most likely the 4.z.RC1. 
 - Similairly, for defects uncovered when testing the 4.z.RC1 code, the milestone field shall be set to 4.z.RC2 or 4.z.0 accordingly as applicable.

-(c) Optionally, you may also update the **Version** field of the ticket to the first version of OpenSAF where the bug was introduced.
+**(c)** Optionally, you may also update the **Version** field of the ticket to the first version of OpenSAF where the bug was introduced.

 **Notes**
 - We maintain the three latest releases of OpenSAF including the release currently under development(i.e. default branch).

Development Process modified by Mathi Naickan

Mathi Naickan — Fri, 07 Aug 2015 11:22:13 -0000

--- v8
+++ v9
@@ -18,7 +18,8 @@
 - If the fix for that defect has to be pushed into all of 4.5.x and 4.6.y and default branches, then you should set the milestone to 4.5.x. But, if the fix has to be pushed only to the 4.6.y and default branches, then you should set the milestone to 4.6.y.

 * When working on an **Enhancement** ticket, then the fix should only be included in the latest release that is currently under development, i.e. the 'default' branch.  For example, if the next enhancement release is 4.z, then the Milestone shall be set to 4.z.FC where FC stands for "feature complete".
-Also, Defects can be uncovered while testing features that are pushed during an *ongoing enhancements release*, i.e. GA tag is not yet applied on that enhancements branch. For such defects the following guidelines are applicable:
+Also, Defects can be uncovered while testing features that are pushed during an *ongoing enhancements release*, i.e. GA tag is not yet applied on that enhancements branch. 
+For such defects the following guidelines are applicable:-
 - For defects uncovered when testing the 4.z.FC taggged code, the milestone field shall be set to the next milestone which is most likely the 4.z.RC1. 
 - Similairly, for defects uncovered when testing the 4.z.RC1 code, the milestone field shall be set to 4.z.RC2 or 4.z.0 accordingly as applicable.

Development Process modified by Mathi Naickan

Mathi Naickan — Fri, 07 Aug 2015 11:21:17 -0000

--- v7
+++ v8
@@ -15,19 +15,20 @@
 * When working on a **Defect**, set the milestone field to the oldest release where the code will be included. This will help in planning the release and tracking what is included in the different OpenSAF releases. The default value in the milestone field is configured to be set to the oldest maintenance release in the pipeline.
 For example:-
 Suppose the two maintenance releases in pipeline are 4.5.x and 4.6.y. Then between these two 4.5.x is the oldest.
-- If the fix for that defect has to be pushed into all of 4.5.x and 4.6.y and default branches, then you should set the milestone to 4.5.x. 
-- But, if the fix has to be pushed only to the 4.6.y and default branches, then you should set the milestone to 4.6.y.
+- If the fix for that defect has to be pushed into all of 4.5.x and 4.6.y and default branches, then you should set the milestone to 4.5.x. But, if the fix has to be pushed only to the 4.6.y and default branches, then you should set the milestone to 4.6.y.

 * When working on an **Enhancement** ticket, then the fix should only be included in the latest release that is currently under development, i.e. the 'default' branch.  For example, if the next enhancement release is 4.z, then the Milestone shall be set to 4.z.FC where FC stands for "feature complete".
 Also, Defects can be uncovered while testing features that are pushed during an *ongoing enhancements release*, i.e. GA tag is not yet applied on that enhancements branch. For such defects the following guidelines are applicable:
 - For defects uncovered when testing the 4.z.FC taggged code, the milestone field shall be set to the next milestone which is most likely the 4.z.RC1. 
 - Similairly, for defects uncovered when testing the 4.z.RC1 code, the milestone field shall be set to 4.z.RC2 or 4.z.0 accordingly as applicable.

-* Notes:
+(c) Optionally, you may also update the **Version** field of the ticket to the first version of OpenSAF where the bug was introduced.
+
+**Notes**
 - We maintain the three latest releases of OpenSAF including the release currently under development(i.e. default branch).
 - All enhancement tickets that are not being currently worked upon should have the **Milestone** field set to 'future'.

-(c) Optionally, you may also update the **Version** field of the ticket to the first version of OpenSAF where the bug was introduced.
+

 Setting up the development environment
 ------------------

Development Process modified by Mathi Naickan

Mathi Naickan — Fri, 07 Aug 2015 11:18:56 -0000

--- v6
+++ v7
@@ -23,8 +23,8 @@
 - For defects uncovered when testing the 4.z.FC taggged code, the milestone field shall be set to the next milestone which is most likely the 4.z.RC1. 
 - Similairly, for defects uncovered when testing the 4.z.RC1 code, the milestone field shall be set to 4.z.RC2 or 4.z.0 accordingly as applicable.

-* Notes: 
-- We maintain the three latest releases of OpenSAF including the release currently under development(i.e. default branch). 
+* Notes:
+- We maintain the three latest releases of OpenSAF including the release currently under development(i.e. default branch).
 - All enhancement tickets that are not being currently worked upon should have the **Milestone** field set to 'future'.

 (c) Optionally, you may also update the **Version** field of the ticket to the first version of OpenSAF where the bug was introduced.

Development Process modified by Mathi Naickan

Mathi Naickan — Fri, 07 Aug 2015 11:17:25 -0000

--- v5
+++ v6
@@ -14,8 +14,8 @@

 * When working on a **Defect**, set the milestone field to the oldest release where the code will be included. This will help in planning the release and tracking what is included in the different OpenSAF releases. The default value in the milestone field is configured to be set to the oldest maintenance release in the pipeline.
 For example:-
-Suppose the two maintenance releases in pipeline are 4.5.x and 4.6.y. Then between these two 4.5.x is the oldest. 
-- If the fix for that defect has to be pushed into all of 4.5.x and 4.6.y and default branches, then you should set the milestone to 4.5.x.
+Suppose the two maintenance releases in pipeline are 4.5.x and 4.6.y. Then between these two 4.5.x is the oldest.
+- If the fix for that defect has to be pushed into all of 4.5.x and 4.6.y and default branches, then you should set the milestone to 4.5.x. 
 - But, if the fix has to be pushed only to the 4.6.y and default branches, then you should set the milestone to 4.6.y.

 * When working on an **Enhancement** ticket, then the fix should only be included in the latest release that is currently under development, i.e. the 'default' branch.  For example, if the next enhancement release is 4.z, then the Milestone shall be set to 4.z.FC where FC stands for "feature complete".