Versions Compared

Old Version 6

changes.mady.by.user David Smiley

Saved on

compared with

New Version 7

changes.mady.by.user Jan Høydahl

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

TODO mention not needing a JIRA issue for these scenarios as well?  Such a proposal needn't block a GitHub PR I suppose, and thus not all  GH PRs need a JIRA issue.

Design reviews with SIP (Solr Improvement Proposals)

Once in a while we do larger architectural changes, introduce new major features/modules or change important public APIs. In such cases there may be a need for a more thorough up-front design review and a vote. Such changes typically span multiple JIRA issues and keeping the high-level design decisions a confluence page rather than in JIRA descriptions helps communicating the overall design. In addition the SIP process forces certain questions to be answered. See the main SIP page for details.

NOTE: The SIP process is still in DRAFT state and may need a vote to implement in the project policies. We may also decide to try it for 6 months and then re-evalute

Tests

There is no real policy on tests, but obviously, we want our code to be tested.  If the proposed changes don't incorporate a test then the issue or GitHub PR (or other review platform) should mention so and why for the benefit of reviewers, unless it's obviously not needed (e.g. already tested via whatever).  Trivial bugs need not.

...