mirror of
https://github.com/urbit/shrub.git
synced 2024-12-24 20:47:27 +03:00
MAINTAINERS: several updates [ci skip]
* 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:
parent
915bf1332f
commit
618cfa862b
107
MAINTAINERS.md
107
MAINTAINERS.md
@ -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.
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user