* Simple replacements of doc.zebra.zfnd.org with docs.rs
* Manual fixes for specific main/internal/external docs
* Point developer docs to doc-internal.zebra.zfnd.org
* fastmod --glob '\!.git' -- doc.zebra.zfnd.org/zebrad docs.rs/zebrad/latest/zebrad
* Manually remove any remaining doc.zfnd.zebra.org links
* Remove the external docs job
* Add changelog entry and fix links
* Fix links that were broken before this PR
* Move releases info to `Building Zebra`
* Move Zebra use-cases to `Using Zebra`
* Point the links in Zebra use-cases to docs
* Move the contents of `Release Candidates`
* Refactor the `System Requirements` link
* Update the syncing times
* Update notes on performance
* Move data usage to `System Requirements`
* Remove "building Zebra" from lightwalletd docs
I think we can assume people will follow the previous parts of the docs
for how to build Zebra.
* Move lightwalletd details from `README.md` to docs
`README.md` already mentions lightwalletd from the `Using Zebra`
section, and refers the reader to the docs where the details were moved
and refactored.
* Mention `lightwalletd` and mining in Running Zebra
* Move Troubleshooting to its own file
* Move "Improving Performance" to its own file
* Move instructions for ARM to "Installing Zebra"
* Reword the Testnet sync duration description
Co-authored-by: Pili Guerra <mpguerra@users.noreply.github.com>
* Move "Improving Performance" to "Troubleshooting"
* Remove the Testnet unreliability caveat
---------
Co-authored-by: Pili Guerra <mpguerra@users.noreply.github.com>
* refuse to run Zebra if it is too old
* update the release checklist to consider the constants
* bring newline back
* apply new end of support code
* attempt to add tests (not working yet)
* move eos to progress task
* move tests
* add acceptance test (not working)
* fix tests
* change to block height checks (ugly code)
* change warn days
* refactor estimated blocks per day, etc
* move end of support code to its own task
* change test
* fix some docs
* move constants
* remove uneeded conversions
* downgrade tracing
* reduce end of support time, fix ci changing debugs to info again
* update instructions
* add failure messages
* cargo lock update
* unify releaase name constant
* change info msg
* clippy fixes
* add a block explorer
* ignore testnet in end of support task
* change panic to 16 weeks
* add some documentation about end of support
* Tweak docs wording
---------
Co-authored-by: teor <teor@riseup.net>
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
* doc(README): remove completed Zebra goals
* doc(README): docker now uses bullseye
* doc(README): clarify and expand disk requirements
* doc(README): add network latency requirement
Also note extra network usage after database format changes.
* doc(run): de-duplicate README info
* doc(run): speed up Zebra's performance
* Improve documentation
* Incorporate text about Zebra from the last newsletter
* Organize README and user docs
* Add table of contents, organize heading levels
* Fix link
* capitalize list items
* fix table of contents
* format spacing issue
Co-authored-by: Alfredo Garcia <oxarbitrage@gmail.com>
Remove the seed command entirely, and make the behavior it provided
(responding to `Request::Peers`) part of the ordinary functioning of the
start command.
The new `Inbound` service should be expanded to handle all request
types.
* Reorganize the book.
This PR has one unfortunate change, which is that the README.md and
CONTRIBUTING.md files in the book are symlinks to files in the parent
directory. The motivation for this is to ensure that we don't maintain two
copies of the same data, and that the landing page of the website matches the
landing page of the Github repo, etc. However, I'm not sure whether these
symlinks will work correctly on Windows.
The alternatives are:
- Duplicate the contents of the files and expect that people will know to keep
them in sync;
- Use relative links `../../README.md` in the `SUMMARY.md`. This seemed like
it caused mdbook to dump the rendered files into the repository root rather
than keeping them in the `book` directory.
- Use a symlink (chosen option). This may not work on Windows but I think that
the worst outcome would be that the book would be unbuildable unless someone
used WSL or something. This seems like the least bad option.
* Remove symlinks in favor of #include
Turns out the symlinks aren't required!