Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

...

  1. Anyone
    1. To indicate an issue should be considered for merging, set the Maintenance Branch's status field (e.g., 2.4.x Status, 2.5.x Status) to "Merge".
  2. Branch Manager
    1. Verify that the issues is appropriate and ready to merge to the Maintenance Branch.
    2. Merge the issue. (If the merge isn't clean, contact the appropriate Project Team for assistance.)
    3. Set the Maintenance Branch's status field to "Resolved" and set the Fix Version to the appropriate maintenance branch version (e.g., 2.4.x, 2.5.x).
  3. Release Team
    1. For issues being included in a maintenance release tag, the maintenance branch Fix Version (e.g., 2.4.x, 2.5.x) needs to be changed to the tag's version number (e.g., 2.5.2-rc01, 2.5.2-rc02, 2.5.2).
  4. QA
    1. Test the fix in the Maintenance Branch.
    2. If successful, then set the Maintenance Branch's status field to "Closed". Otherwise, re-open the issue and assign it back to the appropriate Project Team member (or, if that is not clear, then assign it to Unlicensed Former user (Deleted)), along with an explanation of the problem you've encountered.

...

  • A Jira (of issue type Branch) should be created that proposes what will be done in the branch and explains why it's a good idea. It should also include an estimate of when the work is expected to be completed and ready for merging back to the trunk.
  • There should be a general announcement of the proposal on Sakai-dev, which should contain a pointer to the Jira, where discussion can take place; discussion can take place on sakai-dev as well, and the proposer should summarize such discussion in the Jira or provide a pointer to the thread.
  • The Project Leads for the areas of Sakai that the branch will impact, and any interested parties in the Sakai community, should review the proposal.
  • A request for a branch in SVN to support the work should be sent to svn@collab.sakaiproject.org. The impacted project lead(s) should be cc'ed on the request, so they are aware of the new branch.
  • As work proceeds on the branch, if you would like to use additional Jira Issues to help manage your work, the one caveat is to use Sub-Tasks of the Branch Jira, rather independent issues, in order to aid in distinguishing work going on in the branch from that in trunk. You should also use the generic "branch" version for Fix Versions; this should be updated to Nightly/Trunk-SVN when your work is merged back in.
  • When work on the branch is completed, the issue is Resolved, and ready for review, another announcement should be sent to sakai-dev to alert folks to review the work and express opinions on its return to trunk. At least three working days should allowed for comment and voting.
  • The Project Leads should also review the work and there may be some back-and-forth required here to get the branch into shape for agreement on merging it. If work is rejected, a reason must be provided.
  • If everything checks out okay, then the Project Leads and the branch developers will work together to merge the changes into trunk, and send out a final notice when the merge is completed and the issue is Closed.
    • The Branch issues should be converted to a Task when the decision to merge it back to trunk is made, and the Fix Version should be set appropriately.
    • When the merge is completed, the issue should be Closed. Any subsequent issues that arise, should be dealt with via new Jira Bugs, Tasks, Feature Requests, etc., rather than reopening the original issue.
    • Note that code needs to properly licensed before it can be merged to main Sakai trunk, so it behooves those developing branches to ensure they have completed the necessary employer and employee contributor licensing agreements (CLAs) early in this process. For assistance with this, please contact the Sakai Project Coordinator (Unlicensed Former user (Deleted)).

Anchor
Feature Branches
Feature Branches

...

Also, work should only be checked into trunk that is appropriately covered by Contributor Licensing Agreements (CLAs). This includes patches contributed by others (perhaps attached to a Jira or an email), which you might merge yourself after reviewing them. In practice, no one will be given committ access to trunk until they have completed the appropriate individual and orgainzational CLAs. (For questions regarding licensing in Sakai please contact the Sakai Project Coordinator (Unlicensed Former user (Deleted)) or the Licensing Working Group.)