• Home
  • Line#
  • Scopes#
  • Navigate#
  • Raw
  • Download
1---
2layout: default
3title: Miscellaneous
4parent: Release & Milestone Tasks
5grand_parent: Contributors
6nav_order: 80
7---
8
9<!--
10© 2021 and later: Unicode, Inc. and others.
11License & terms of use: http://www.unicode.org/copyright.html
12-->
13
14# Miscellaneous
15{: .no_toc }
16
17## Contents
18{: .no_toc .text-delta }
19
201. TOC
21{:toc}
22
23---
24
25## Complete code reviews
26
27Nag all the reviewers to finish reviewing the code and change the status of
28bugs.
29
30---
31
32## Check in serialization compatibility test data
33
34ICU4J unit test contains serialization compatibility test cases. When a new
35reference version is released, we build serialized object data with the version
36and use it for future testing.
37
381.  Run "ant serialTestData" at ICU4J root directory
392.  The target generates test data and runs some serialization test cases.
403.  Once you confirm the test runs clean, copy
41    `out/serialTestData/ICU_<version>` to
42    `main/tests/core/src/com/ibm/icu/dev/test/serializable/data/ICU_<version>`.
43
44---
45
46## Release ticket
47
48After every milestone (GA / RC / Milestone-N) is completed, create a new release
49ticket in ICU Jira.
50The release ticket is used for BRS tasks, such as version update, tagging new version,
51merging post RC fixes from trunk and others.
52
53---
54
55## Check integrity of Jira issues in commit messages
56
57Every commit being shipped in the next ICU release should be labeled with a Jira
58ticket that is marked as fixed with the correct fix version. Further, there
59should be no Jira tickets marked as fixed with the current fixVersion that do
60not have commits. To check this, run the following tool:
61
62<https://github.com/unicode-org/icu/tree/main/tools/commit-checker>
63
64Follow the instructions in the README file to generate the report and send it
65for review.
66
67---
68
69## Fix Mis-ticketted commits
70
71If the commit checker tool above reports any malformed commit messages, it might
72mean that a bad commit made its way onto ICU main branch. To fix this, a rebase
73is required. Since rebases can be disruptive, confirm with ICU-TC before
74performing one. If ICU-TC agrees to perform a rebase, initiate the process as
75follows:
76
77$ git checkout main; git pull --ff-only upstream main
78
79$ git rebase -i --preserve-merges latest
80
81Note: although tempting, please do not use --committer-date-is--author-date. It
82changes the order of commits in ways we don't want to do.
83
84In the interactive rebase window, choose commit messages to rewrite using the
85"reword" option. Save and exit the interactive screen, and then edit each commit
86message.
87
88When ready, force-push the main branch to your fork and give ICU-TC a day or two
89to review. Before force-pushing to upstream, create a new branch on upstream
90with the latest commit on the old main branch; name it something like
91"pre63-old-main".  When ready, disable branch protection on main, force-push,
92and then reapply branch protection. Create a new branch named something like
93"pre63-new-main" to allow users to easily switch between the two heads.
94
95Send an email to icu-support explaining the change and how to deal with it. You
96can use [this email](https://sourceforge.net/p/icu/mailman/message/36426642/) as
97a model.
98
99---
100
101## Scrub closed issues in code
102
103(1) Search for "TODO(12345)" to detect TODO items for closed issues.
104
105(2) Do the same for logKnownIssue. (the data related logKnownIssues are often
106addressed during CLDR data integration)
107
108If the TODO or logKnownIssue references a closed issue, if the problem is fixed,
109remove the TODO/logKnownIssue, or if the problem is not fixed, open a new issue
110and update the reference in the code.
111