Read before contributing

Boring Techniques

This document is intended to help you write safe, dull, simple, boring, pedestrian code. These qualities are valuable because programming is hard, and debugging is harder, and debugging distributed systems is harder still; but by writing all our code with a determinedly po-faced and dyspeptic cynicism, and by tightly proscribing the interactions between components, we can at least limit the insanity we have to deal with at any one time.

There are valid exceptions to many of these maxims, but they are rare and you should not violate them without a bone-deep understanding of why they exist and what their purpose is. (Before tearing down a fence, know why it was put up.)

https://discourse.jujucharms.com/t/how-to-write-and-apply-a-bug-fix-for-juju/2755

When fixing a bug that affects more than a single branch the prefered
process for fixing the bug is to perform the work against the oldest
branch (back porting) and then apply that patch up to each release branch
and finally in to master.

Sections

  • How to backport
  • Patching 3rd Party Libraries

https://discourse.jujucharms.com/t/code-review-checklists/2733

This document contains checklists to use when reviewing changes to Juju core. They have been synthesised from various documents written over Juju’s history as well as issues that have been raised on actual reviews. These checklists don’t cover every possible thing that a reviewer should be thinking of when looking at a proposed change. The focus is on the biggest wins that can be practically included in a checklist.

https://discourse.jujucharms.com/t/continuous-integration-testing/2756

Juju has many Continuous Integration (CI) tests that run whenever new code is checked in. These are long-running integration tests that do actual deploys to clouds, to ensure that juju works in real-world environments.

1 Like