urbit/shrub
1
1
Fork 0
mirror of https://github.com/urbit/shrub.git synced 2024-12-25 04:52:06 +03:00
Code Issues Packages Projects Releases Wiki Activity

MAINTAINERS: several updates [ci skip]

Browse Source 
* recommend using sh/merge-with-custom-msg
* recommend cherry-picking merge commits
* drop hep from release candidate tag format
* minor other additions
This commit is contained in:
Jared Tobin 2020-02-18 16:51:07 +04:00
parent 915bf1332f
commit 618cfa862b
No known key found for this signature in database
GPG Key ID: 0E4647D58F8A69E4
1 changed files with 72 additions and 35 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

107
MAINTAINERS.md
View File

@ -5,9 +5,9 @@
Here lies an informal guide for making hotfix releases and deploying them to
the network.
Take [this recent PR][1], as an example. This constituted a great hotfix.
It's a single commit, targeting a problem that existed on the network at the
time. Here's it should be released and deployed OTA.
Take [this PR][1], as an example. This constituted a great hotfix. It's a
single commit, targeting a problem that existed on the network at the time.
Here's it should be released and deployed OTA.
[1]: https://github.com/urbit/urbit/pull/2025
@ -16,14 +16,9 @@ time. Here's it should be released and deployed OTA.
Unless it's very trivial, it should probably have a single "credible looking"
review from somebody else on it.
You can just merge the PR in GitHub. As I, `~nidsut-tomdun`, am a l33t
h4x0r, I use a custom merge commit format, gotten by:
```
git merge --no-ff --signoff --log BRANCH
```
with the commit message:
You should avoid merging the PR in GitHub directly. Instead, use the
`sh/merge-with-custom-msg` script -- it will produce a merge commit with
message along the lines of:
```
Merge branch FOO (#PR_NUM)
@ -32,21 +27,29 @@ Merge branch FOO (#PR_NUM)
bar: ...
baz: ...
Signed-off-by: Jared Tobin <jared@tlon.io>
Signed-off-by: SIGNER <signer@example.com>
```
All this extra wankery is hardly required, but IMO it's nice to have the
commit log information in the merge commit, which GitHub's "Merge PR" button
doesn't do (at least by default).
We do this as it's nice to have the commit log information in the merge commit,
which GitHub's "Merge PR" button doesn't do (at least by default).
`sh/merge-with-custom-msg` performs some useful last-minute urbit-specific
checks, as well.
The script at `sh/merge-with-custom-message` can be used to make this simple(r)
to do. I use `git mu` as an alias for it, locally.
You might want to alias `sh/merge-with-custom-msg` locally, to make it easier
to use. My .git/config contains the following, for example:
```
[alias]
mu = !sh/merge-with-custom-msg
```
so that I can type e.g. `git mu origin/foo 1337`.
### Apply the changes to this era's release branch
This corresponds to the 'vx.y' part of the most recent 'urbit vx.y.z' release.
At the time of writing, we're on v0.10 (and I'll use this branch as a running
example):
For now, the release branch corresponds to the `vx.y` part of the most recent
Vere release (i.e., `urbit vx.y.z`). At the time of writing, we're on v0.10
(and I'll use this branch as a running example):
If the branch doesn't yet exist, just create it via:
@ -55,8 +58,8 @@ git checkout -b v0.10 master
```
If you can get away with merging master to v0.10 without pulling in any
superfluous commits, feel free to do that. Otherwise, you'll want to cherry
pick the commits like so:
superfluous or non-OTA-able commits, feel free to do that. Otherwise, you'll
want to cherry pick the commits like so:
```
git cherry-pick -x TARGET_COMMITS
@ -65,12 +68,43 @@ git cherry-pick -x TARGET_COMMITS
Use the `-x` flag to `git-cherry-pick`, because this will indicate in the
commit message where the things originally came from.
A useful technique is to cherry-pick merge commits on master directly. Take
following commit, for example:
```
commit 769996d09
Merge: 171fcbd26 8428f0ab1
Author: Jared Tobin <jared@tlon.io>
Date: Sun Feb 2 19:11:04 2020 +0400
Merge branch 'liam-fitzgerald/langserver-doc-autocomplete' (#2204)
* liam-fitzgerald/langserver-doc-autocomplete:
language-server: magic-spoon hover, autocomplete
language-server: build ford prelude
language-server: dynamically compute subject
language-server: revive rune/symbol completion
language-server: add completion JSON parsers
Signed-off-by: Jared Tobin <jared@tlon.io>
```
rather than cherry-picking the individual commits, one could just use the
following while on the release branch:
```
git cherry-pick -x -m 1 769996d09
```
you can check the man page for `git-cherry-pick(1)` for details here.
Create Landscape or alternative pill builds, if or as appropriate (i.e., if
anything in Landscape changed -- don't trust the compiled JS/CSS that's
anything in Landscape changed -- don't trust any compiled JS/CSS that's
included in the commit).
You may also want to create a brass pill, in particular, as it's convenient for
tooling to be able to boot directly from a given release.
You should always create a solid pill, in particular, as it's convenient for
tooling to be able to boot directly from a given release. If you're making a
Vere release, just play it safe and update all the pills.
### Tag the resulting commit
@ -106,8 +140,7 @@ You can get the "contributions" section by the shortlog between the
last release and this release:
```
git log --pretty=short --no-merges \
LAST_RELEASE..v0.10 | git shortlog
git log --pretty=short LAST_RELEASE.. | git shortlog
```
I originally tried to curate this list somewhat, but now just paste it
@ -121,7 +154,7 @@ If the commit descriptions are too poor to easily do this, then again, yell at
your fellow contributors to make them better in the future.
If it's *not* a trivial hotfix, you should probably make any number of release
candidate tags (e.g. `arvo.yyyy.mm.dd.rc-1`, `arvo.yyyy.mm.dd.rc-2`, ..), test
candidate tags (e.g. `arvo.yyyy.mm.dd.rc1`, `arvo.yyyy.mm.dd.rc2`, ..), test
them, and after you confirm one of them is good, tag the release as
`arvo.yyyy.mm.dd`.
@ -150,13 +183,17 @@ Contributions:
The same schpeel re: release candidates applies here.
You should probably avoid putting both Arvo and Vere changes into Vere
releases.
Do not include implicit Arvo changes in Vere releases. This used to be done,
historically, but shouldn't be any longer. If there are Arvo and Vere changes
to be released, make two releases.
### Deploy the update
For Arvo updates, this means copying the files into ~zod's %base desk. For
consistency, I download the release tarball and then rsync the files in:
For Arvo updates, this means copying the files into ~zod's %base desk. The
changes will be synced to /~zod/kids and then propagated through other galaxies
and stars to the rest of the network.
For consistency, I download the release tarball and then rsync the files in:
```
$ wget https://github.com/urbit/urbit/archive/arvo.yyyy.mm.dd.tar.gz
@ -166,13 +203,13 @@ $ rsync -zr --delete urbit-arvo.yyyy.mm.dd/pkg/arvo/ zod/base
$ herb zod -p hood -d "+hood/commit %base"
```
For Vere updates, this means shutting down each desired ship, installing the
new binary, and restarting the pier with it.
For Vere updates, this means simply shutting down each desired ship, installing
the new binary, and restarting the pier with it.
### Announce the update
Post an announcement to urbit-dev. The tag annotation, basically, is fine here
-- I usually add the %base hash (for Arvo releases) and the release binary URLs
(for Vere releaes). Check the urbit-dev archives for examples of these
(for Vere releases). Check the urbit-dev archives for examples of these
announcements.