Core Committer Process

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.

  1. Choose a Launchpad Ticket
    • Ideally, choose a ticket that has the pullrequest and signedoff tags.
    • If it only has the pullrequest tag, you will be responsible for the testing and signoff stage as well as the committing stage.
  2. Review, Install, Test
    1. Review the Code
      • Code formatting - whitespace, etc.?
      • Consistency with other code?
      • Good variable names, clear comments?
      • Logically well-constructed?
      • Descriptive commit messages?
      • Release notes?
      • Documentation?
      • Does it need to be rebased to current main? You may do this yourself or ask the original submitter to do so (add the “needsrebase” tag if so).
      • Are there multiple commits? Some patches may be intentionally split into multiple logical commits, but other patches may just have minor changes and corrections in multiple commits that can be squashed for clarity. Creating a local branch to handle the squashing can be useful, or you may wish to refer it back to the original submitter (add the "needswork" tag if so).
    2. Install the Code
      • This will vary depending upon your development environment.
    3. Test the Code
      • Your level of testing will vary depending on code complexity and how well you understand what it is doing.
      • Does it work in the UI?
      • Are there database changes? If so, is there an upgrade script that matches the database changes?
      • 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?
  3. Begin the Merge
    1. git checkout main
    2. git pull origin main
    3. git remote update
    4. git cherry-pick -s [branch id]
      • For multiple commits on a branch: git cherry-pick -s [oldest hash]^..[newest hash]
    5. git commit –amend
    6. Add signoffs as needed (review Launchpad ticket)
    7. Amend title if needed (make sure it includes LP number)
    8. Add Release Note line if needed:
      • Release-note: Adds publication year to pull list.
  4. Handle Upgrade Script (if relevant)
    1. When a database upgrade script is needed, it should be located in Open-ILS/src/sql/Pg/upgrade
    2. Look at current repo to see the next upgrade number (if backporting, use this same number)
    3. Post in IRC that you will be using the next number:
      • "Claiming 1438"
    4. 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);
    5. Change the file name from XXXX to new number
      • git mv oldfilename newfilename
    6. 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
    7. Double-check everything:
      • git status
      • git diff
    8. Stage the changes:
      • git add .
    9. Create a commit that just includes the Launchpad number and "Stamp upgrade script":
      • git commit -sm "LP123456 Stamp upgrade script"
  5. 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)
  6. Merge
    • You can do a dry run first: git push –dry-run
    • Do the merge: git push
  7. 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.
  8. 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.