| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| contributing [2017/02/28 15:35] – [Before you contribute] rjs7 | contributing [2025/03/20 12:18] (current) – jdavis |
|---|
| The Evergreen project primarily uses the [[https://bugs.launchpad.net/evergreen|Evergreen]] and [[https://bugs.launchpad.net/opensrf|OpenSRF]] Launchpad instances to track reported bugs. To avoid duplication in the bug reporting database, search for an existing bug that matches your problem before opening a new bug. If you have found a new bug, try to be as specific as possible when reporting the problem; include information such as the specific versions of OpenSRF, Evergreen, PostgreSQL, XULRunner, and other components as well as the Linux distribution that you're using. Communication about the bug will occur on the bug form itself, and you will automatically be added to the email list for that bug to be notified when updates to the bug occur. | The Evergreen project primarily uses the [[https://bugs.launchpad.net/evergreen|Evergreen]] and [[https://bugs.launchpad.net/opensrf|OpenSRF]] Launchpad instances to track reported bugs. To avoid duplication in the bug reporting database, search for an existing bug that matches your problem before opening a new bug. If you have found a new bug, try to be as specific as possible when reporting the problem; include information such as the specific versions of OpenSRF, Evergreen, PostgreSQL, XULRunner, and other components as well as the Linux distribution that you're using. Communication about the bug will occur on the bug form itself, and you will automatically be added to the email list for that bug to be notified when updates to the bug occur. |
| |
| If you wish to join the "Bug Wranglers" group that maintains the Evergreen bug reporting database, just add yourself to [[https://launchpad.net/~evergreen-bugs|the team]]. | If you wish to join the "Bug Wranglers" group that maintains the Evergreen bug reporting database, just add yourself to [[https://launchpad.net/~evergreen-bugs|the team]]. For details on how we use Launchpad (such as what the different bug statuses mean), read the [[dev:bug_wrangler:faq|Evergreen Bug Wrangler FAQ]]. |
| |
| ===== Offering support ===== | ===== Offering support ===== |
| - collect the information on a page on the Evergreen wiki in the [[http://evergreen-ils.org/dokuwiki/doku.php?idx=dev%3Aproposal|dev:proposal namespace]] | - collect the information on a page on the Evergreen wiki in the [[http://evergreen-ils.org/dokuwiki/doku.php?idx=dev%3Aproposal|dev:proposal namespace]] |
| - add a [[https://bugs.launchpad.net/evergreen|Launchpad bug]] with the basic overview and a link to the corresponding wiki page | - add a [[https://bugs.launchpad.net/evergreen|Launchpad bug]] with the basic overview and a link to the corresponding wiki page |
| - send the basic overview and links to the Launchpad bug and wiki page to the [[http://libmail.georgialibraries.org/mailman/listinfo/open-ils-dev|Evergreen development mailing list]] and/or the [[http://libmail.georgialibraries.org/mailman/listinfo/open-ils-general|general mailing list]]with a subject line beginning with Feature Proposal | - send the basic overview and links to the Launchpad bug and wiki page to the [[http://libmail.georgialibraries.org/mailman/listinfo/open-ils-dev|Evergreen development mailing list]] and/or the [[http://libmail.georgialibraries.org/mailman/listinfo/open-ils-general|general mailing list]] with a subject line beginning with Feature Proposal |
| |
| |
| 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: | 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. | * 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: | * 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> | <code bash> |
| $ git checkout -b working_branch master | $ git checkout -b working_branch main |
| |
| # hack away | # hack away |
| * Any time a patch adds or alters a stored procedure, pgTAP tests that exercise its intended functionality should be included. | * 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. | * 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]] | * 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. | * Bug fix patches should explain how to test the bug fix in the commit message. |
