Differences

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

--- contributing [2022/02/10 13:34] – external edit 127.0.0.1
+++ contributing [2025/03/20 12:18] (current) – jdavis
@@ Line 120: / Line 120: @@
 It will be reviewed by other contributors to the project and will be either accepted or sent back for further work. To help ensure your patch is reviewed and committed in a timely fashion, please ensure your submission conforms to the following guidelines:
-  * Ensure that your branch or patch is developed against the most recent version of the code, which for developers is the master branch in the [[http://git.evergreen-ils.org/?p=Evergreen.git;a=summary|Evergreen Git repository]].
+  * Ensure that your branch or patch is developed against the most recent version of the code, which for developers is the main branch in the [[http://git.evergreen-ils.org/?p=Evergreen.git;a=summary|Evergreen Git repository]].
   * Try to make your changes as readable as possible by following the surrounding code-layout conventions. This makes it easier for the reviewer, and there's no point in trying to lay out things differently. Also, avoid unnecessary white space changes because they just distract the reviewer, and formatting changes will likely be removed by the committing core team member.
   * If you are submitting a patch rather than pointing at a branch in a public repository, use the Git ''format-patch'' command after updating your working copy of the repository or module as follows:
 <code bash>
-$ git checkout -b working_branch master
+$ git checkout -b working_branch main
 # hack away
@@ Line 161: / Line 161: @@
     * Any time a patch adds or alters a stored procedure, pgTAP tests that exercise its intended functionality should be included.
     * A change to database or Perl code that fixes a bug should be accompanied by a Perl (t or live_t) or pgTAP regression test – or by a statement from the patch author explaining why a test is infeasible without significant refactoring. In the latter case, it is expected that an extra signoff be obtained before the patch is merged.
+    * Changes to the Angular staff client should be run through a linter to catch inconsistencies and common errors (cd Open-ILS/src/eg2 && npx ng lint).
   * New features should be accompanied by a file in the repository under the docs/RELEASE_NOTES_NEXT/ directory.  The file should be in asciidoc format and contain enough description to enable the documentation team to write something coherent about the new functionality.  The name of the file should match the feature.  No numbering, etc. is required.  With each release, the contents of this directory will be appended to the release notes. [[contributing:release_notes|See Tips for Writing Release Notes]]
   * Bug fix patches should explain how to test the bug fix in the commit message.