Most of what makes a Zulip migration tricky to write follows from
how Zulip Cloud deploys: staging and production share a database,
staging deploys first and runs the migration against the shared
DB, production deploys some time later, and Django processes
restart in a rolling fashion. Together these mean migrations must
be safe for the previous release's code to keep running against,
and that staging-time problems are also live production problems.
The previous version of this page didn't describe any of that,
and as a result didn't motivate most of the rules contributors
need to follow. Rework the page around the deploy model so each
rule traces back to a property of how migrations actually run on
Cloud.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Fedora 44 ships Postgres 17 in PGDG and shares Fedora 43's package
list, so support is just a matter of accepting the new version in
the provision check.
Fedora 38 reached end of life upstream; replace it with Fedora 43,
which ships dnf5 and a recent enough groonga to skip the source
build. Concretely, to make `tools/provision` run cleanly on
Fedora 43:
* dnf5 (Fedora 41+) dropped the `groupinstall` alias and no longer
resolves the "Development Tools" display name, so switch the
Fedora branch of `setup-yum-repo` to
`dnf group install development-tools` (by group ID). Move the
existing CentOS/RHEL `groupinstall` calls into their own branches
so they keep working on yum/dnf4.
* Map Fedora 43 to PostgreSQL 17, and add `groonga-devel`,
`xxhash-devel`, `meson`, and `redhat-rpm-config` to the Fedora
package list. PGroonga 4.0.6 switched its build system to meson;
on Fedora, PostgreSQL's `pg_config` exports CFLAGS containing
`-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1` and
`-specs=.../redhat-annobin-cc1`, and without `redhat-rpm-config`
the PGroonga build fails with "cannot read spec file".
`xxhash-devel` is required because `xxhash-libs` is often pulled
in transitively (by blosc2, pyarrow, etc.) without its headers,
in which case meson detects libxxhash via pkg-config and skips
the vendored fallback that would otherwise build it from source.
* Use the packaged groonga from Fedora's main repo (15.0.4 on
Fedora 43, satisfying PGroonga 4.0.6's >= 14.1.0 requirement)
instead of compiling groonga from source. This removes the only
remaining caller of `scripts/lib/build-groonga` and the
BUILD_GROONGA_FROM_SOURCE plumbing in provision.py, which the
prior Fedora 38 path was the only user of.
Verified end-to-end on a Fedora 43 host and in a fresh fedora:43
podman container: setup-yum-repo, the package install, and the
PGroonga source build against the system groonga all complete
cleanly.
The Docker documentation[1] recommends using the
`usermod` command for adding a user to the `docker`
group.
The previous `adduser` command only worked for
Debian-based systems and is symlinked to
`useradd` on my Fedora 43 by default.
I also add the step to create the `docker` group
which wasn't present previously and is a pre-req
for adding $USER to the `docker` group.
[1]: https://docs.docker.com/engine/install/linux-postinstall/
Signed-off-by: apoorvapendse <apoorvavpendse@gmail.com>
Clarifies that adding a user to the docker group requires logging out
and back in (not a full reboot), and explains that Docker must be
running as a background daemon for Docker commands to work.
This commit adds steps to troubleshoot errors encountered
because of certain services like postgresql not starting
on WSL2.
The common reason behind this is port conflicts with other
services running on some other WSL2 instance or the host
Windows system.
This commit provides a guide to handle these issues, and
also provides some additional tips to WSL2 users to avoid
facing these issues in the future.
Fixes#32718.
The assumption here is that VirtualBox is used only for Windows. This
is because we do not mention VirtualBox for Unix based platforms prior
to this troubleshooting errors section.
Prep for organizing common errors into operating systems tabs.
This change is done as a prerequisite step to
eventually add tabs for different platforms
for the troubleshooting section.
The reason behind making this change is to group
the errors common to vagrant setup when using
either docker or VirtualBox backends which would
make it convenient to maintain in the future.
This removes the bug reporting steps from
the intro of the setup tutorial, as it
is already present in the `Troubleshooting
and common errors` section.
Previously, the rebuild steps for WSL in the recommended setup guide
incorrectly just included the Vagrant instructions.
This commit fixes the issue by adding the appropriate steps to delete
the WSL instance using `wsl --unregister` in the docs.
Additionally, it includes steps to rebuild the development database,
which is a much faster alternative for folks who just want that.
Fixes#32402.
This change ensures that developers use a fresh WSL instance when setting up the Zulip environment locally. Doing so helps prevent dependency and versioning conflicts.
Updates all the https://chat.zulip.org/#narrow/stream/ links in the
docs and comments to use the new /channel/ path. All these links are
for documentation/reference purposes only and thus, can be bulk-updated.
This commit is a part of the effort to rename stream to channel.
Since the docker macOS setup doesn't work without this, it makes
sense for it to be just part of the setup instead of a thing
they fix after running into failure.
Updates descriptive text that refer to Zulip channels in the
`docs/development` files to use channel instead of stream.
Part of the stream to channel rename project.
