Differences

This shows you the differences between two versions of the page.

--- contributing:core_committer_process [2025/02/25 14:38] – tmccanna
+++ contributing:core_committer_process [2025/03/20 12:23] (current) – jdavis
@@ Line 1: / Line 1: @@
 ====== Core Committer Process ======
-These instructions are meant as an introductory, step-by-step guide for new Core Committers.
+These instructions are meant as an introductory, step-by-step guide for new core committers. More experienced committers may have alternate workflows that accomplish the same goals.
   - **Choose a Launchpad Ticket**
@@ Line 25: / Line 25: @@
       * Are there Perl/PostgreSQL/NPM-level tests to run?
       * Are there any error messages generated in the server logs?
+      * Does ng lint report any issues?
   - **Begin the Merge**
       - git checkout main
@@ Line 36: / Line 37: @@
       - Add Release Note line if needed:
         * Release-note: Adds publication year to pull list.
-  -
+  - **Handle Upgrade Script (if relevant)**
+    - When a database upgrade script is needed, it should be located in Open-ILS/src/sql/Pg/upgrade
+    - Look at current repo to see the next upgrade number (if backporting, use this same number)
+    - Post in IRC that you will be using the next number:
+      * "Claiming 1438"
+    - Make sure that the upgrade script includes the deps_block line and update it with the new number:
+      * SELECT evergreen.upgrade_deps_block_check('1438', :eg_version);
+    - Change the file name from XXXX to new number
+      * git mv oldfilename newfilename
+    - Update 002.schema.config.sql line 95 (or so) with new number and the current patch's signoffs:
+      * INSERT INTO config.upgrade_log (version, applied_to) VALUES ('1438', :eg_version); -- jdoe, rsmith, awalker
+    - Double-check everything:
+      * git status
+      * git diff
+    - Stage the changes:
+      * git add .
+    - Create a commit that just includes the Launchpad number and "Stamp upgrade script":
+      * git commit -sm "LP123456 Stamp upgrade script"
+  - **Rebase**
+    * git pull --rebase
+    * This isn't always necessary, but it's a good idea especially when other people may be merging commits at the same time (such as during Bug Squashing Weeks)
+  - **Merge**
+    * You can do a dry run first: git push --dry-run
+    * Do the merge: git push
+  - **Backport?**
+    * Decide whether or not the change should be backported. If so, repeat process for whichever actively supported versions it needs to go into (rel_3_12, etc.).
+    * Good reasons to backport:
+      * It is a fix for a bug that was present in a previous release.
+      * It has security implications.
+    * Good reasons not to backport:
+      * It is a fix for a bug that has only appeared in the current release.
+      * It is a new feature.
+      * It does not backport cleanly.
+      * It changes workflow or display in a disruptive way.
+  - **Update Launchpad**
+    * Make sure that Launchpad lists each of the versions that you merged the commit to.
+    * Update the status of each to Fix Committed.
+    * Add a comment indicating that you've merged the change (and it's always nice to thank the contributor and testers!)
+    * Remove yourself from the assignment.