Why ?

There a developers working across 4 time zones, working almost 24 hours to add code / fix bugs in Sailfin and GlassFish. This can easily lead to instability of the build i.e. there maybe compile time errors, or functionality maybe broken. Hence a set of guidelines are recomended, which MUST be followed by each developer, before checking in any code. These guidelines are different for different stages of the project. There are guidelines for the Beta Phase and for normal phase.

Restricted and Open Spaces

Restricted Space means - when we are working towards a Beta OR FCS release on a branch created for that purpose. This is a stabilization phase and occurs after the Hard Code Freeze.
Open Space - means the we open the CVS for all checkins and we are either fixing all bugs, enhancing features.

1.0 Changes in Sailfin (Open Space)

If you are making changes into the SailFin codebase.

1.1 Entry Criteria

We are now past the Feature Freeze period ( since 1/21) and hence you need to have a bug ID (issue ID) corresponding to a checkin. The checkin would happen

1.2 Process

Please refer to the page here for the checkin process

2.0 Changes in GlassFish related to Sailfin (Open Space )

If you are changing code in GlassFish SJSAS91_FCS_BRANCH and these changes arise from a requirement from Sailfin

2.1 Entry Criteria

We are now past the Feature Freeze period ( since 1/21) and hence you need to have a bug ID (issue ID) corresponding to a checkin. The issue id needs to be from Sailfin Issue Tracker

2.2 Process

Please refer to the page here for checkin process

3.0 Changes in Sailfin and Changes in GlassFish arising from Sailfin( Restricted Space )

3.1 Entry Criteria

3.1.1 Beta

1. There MUST be an issue id for each checkin whether its a bug or an feature enhancement.
2. Only high priority (P1, P2, S1) bug fixes will be allowed in the beta branch.
3. For FCS , all bugs P1,P2,P3 must be fixed.
4. For Sailfin,the bugs would be discussed as a part of BugSWAT / BugScrub. Please attend this meeting to provide information on the fix and the justification for the fix.
5. For GlassFish all checkins would need to go through approval process. Please send a mail to Prasad.subramanian@sun.com and cc Harpreet Singh@sun.com and srikanth.anandal@sun.com for approval
6. A branch will be created in both the Sailfin and GlassFish CVS repositories after HCF. See the Milestone page for details
7. Fixes that gets checked into beta branch will also need to be fixed in the main branch (SJSAS91_FCS_BRANCH and MAIN) until beta.
8. Other issues not approved by BugScrub can be checked into main branch

3.1.2 FCS

1. There MUST be an issue id for each checkin whether its a bug or an feature enhancement.
2. For FCS , all bugs P1,P2,P3 must be fixed.
3. For Sailfin,the bugs would be discussed as a part of BugSWAT / BugScrub. Please attend this meeting to provide information on the fix and the justification for the fix.
4. For GlassFish all checkins would need to go through approval process. Please send a mail to Prasad.subramanian@sun.com and cc Harpreet Singh@sun.com and srikanth.anandal@sun.com for approval
5. The following steps list the process post HCF
6. A branch will be created in both the Sailfin and GlassFish CVS repositories after HCF.
7. All checkins must have a corresponding issue , and needs to be approved by BugScrub before checkin. The approval will be reflected in the Issue Tracker by adding a keyword sf10-fcs-approved to the issue.
8. If there is a new issue filed, it needs to be discussed at BugScrub. Once approved , it would have to be checked into the FCS branch and also need to be checkedin into the main branch (SJSAS91_FCS_BRANCH and MAIN) until FCS .
9. Other issues not approved by BugScrub can be checked into main branch alone
10. If there are issues which are deemed for next release, they will have to be evaluated and marked as P4.

3.2 Process

1. Please refer to the page here for checkin process.
2. Once an issue has been fixed, please update the Issue Tracker with the details of the fix mentioned in Section 7 below

4.0 GlassFish changes (Open Space)

If you are changing code in GlassFish SJSAS91_FCS_BRANCH

4.1 Entry Criteria

Please see section 8.0 below.

4.2 Process

1. Please get the code reviewed by the GlassFish module owner to review code.
2. At a minimum the following tests should be run :

• GlassFish QL (both PE and EE)

5.0 GlassFish Related Changes (Restricted Space)

5.1 Entry Criteria

1. If a bug has already been pre-approved for this release, checkin your code into main branch (SJSAS91_FCS_BRANCH)
2. For any new issues that are not in GFv2ur1 and have to make it into the SailFin branch, please fill out the following questionnaire New Bug Submission Criteria for GF v2.1.1

5.2 Process

1. Please get the code reviewed by the GlassFish module owner to review code.
2. At a minimum the following tests should be run

• GlassFish QL (both PE and EE)

6.0 Contents of the Checkin messages

• Bug id ( if any)
• Reviewer names
• Tests run
• Comment on the code changes

7.0 Updating Issue Tracker for bug fixes

• Please mark the bug as FIXED.
• Update the Issue with the evaluation of the problem and the details of how the issue has been fixed.
• Also add details of the files changed by the fix in the bug report. e.g. Add the cvs commit logs from the console that shows which files got updated ( alongwith the new version and old version). The other option is to point a link to FishEye changelog corresponding to this commit.
• Ensure that you update the 'Target Milestone' field with the build in which this issue has been fixed.

8.0 GlassFish v2.1 New Issues Submission Criteria

For any new issues that are not in GFv2ur1 and have to make it into the SailFin branch. Please fill out the following questionnaire.
New Bug Submission Criteria for GF v2.1.1

These guidelines are not meant to add additional burden , rather they are intended to make life predictable for all of us.

Please send feedback to dev@sailfin.java.net