From e8568b505816b1aa60ab7f064fcfc8b16fb26176 Mon Sep 17 00:00:00 2001 From: Daniel Oaks Date: Wed, 11 Apr 2018 22:58:32 +1000 Subject: [PATCH] developing: Update docs as suggested by @enckse --- DEVELOPING.md | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/DEVELOPING.md b/DEVELOPING.md index af5c83a5..5fb19970 100644 --- a/DEVELOPING.md +++ b/DEVELOPING.md @@ -1,10 +1,15 @@ # Developing Oragono -Most development happens on the `develop` branch, which is occasionally rebased + merged into `master` when it's not incredibly broken. When this happens, the `develop` branch is usually pruned until I feel like making 'unsafe' changes again. +This is just a bunch of tips and tricks we keep in mind while developing Oragono. If you wanna help develop as well, they might also be worth keeping in mind! -I may also name the branch `develop+feature` if I'm developing multiple, or particularly unstable, features. -The intent is to keep `master` relatively stable. +## Branches + +The `master` branch should be kept relatively runnable. It might be a bit broken or contain some bad commits now and then, but the pre-release checks should weed those out before users see them. + +For either particularly broken or particularly WiP changes, we work on them in a `develop` branch. The normal branch naming is `develop+feature[.version]`. For example, when first developing 'cloaking', you may use the branch `develop+cloaks`. If you need to create a new branch to work on it (a second version of the implementation, for example), you could use `develop+cloaks.2`, and so on. + +Develop branches are either used to work out implementation details in preperation for a cleaned-up version, for half-written ideas we want to continue persuing, or for stuff that we just don't want on `master` yet for whatever reason. ## Releasing a new version @@ -17,6 +22,7 @@ The intent is to keep `master` relatively stable. 6. Commit the new changelog and constants change. 7. Tag the release with `git tag v0.0.0 -m "Release v0.0.0"` (`0.0.0` replaced with the real ver number). 8. Build binaries using the Makefile, upload release to Github including the changelog and binaries. +9. If it's a proper release (i.e. not an alpha/beta), merge the updates into the `stable` branch. Once it's built and released, you need to setup the new development version. To do so: @@ -81,6 +87,7 @@ To debug a hang, the best thing to do is to get a stack trace. Go's nice, and yo This will kill Oragono and print out a stack trace for you to take a look at. + ## Concurrency design Oragono involves a fair amount of shared state. Here are some of the main points: @@ -100,6 +107,7 @@ There are some mutexes that are "tier 0": anything in a subpackage of `irc` (e.g We are using `buntdb` for persistence; a `buntdb.DB` has an `RWMutex` inside it, with read-write transactions getting the `Lock()` and read-only transactions getting the `RLock()`. This mutex is considered tier 1. However, it's shared globally across all consumers, so if possible you should avoid acquiring it while holding ordinary application-level mutexes. + ## Command handlers and ResponseBuffer We support a lot of IRCv3 specs. Pretty much all of them, in fact. And a lot of proposed/draft ones. One of the draft specifications that we support is called ["labeled responses"](https://ircv3.net/specs/extensions/labeled-response.html).