Proposing a MAINTENANCE file #81
@@ -0,0 +1,96 @@
|
||||
# Nextcloud Recipe Maintenance
|
||||
|
||||
> Status: **DRAFT** — open for discussion with co-maintainers and the wider
|
||||
> federation. Sections marked _(TBD)_ need collective input before this
|
||||
> document is considered ratified.
|
||||
|
||||
This document describes how the Nextcloud recipe is maintained. It builds on
|
||||
the floor set by [Federation Resolution
|
||||
025](https://docs.coopcloud.tech/federation/resolutions/passed/025/) and
|
||||
follows the [`MAINTENANCE.md`
|
||||
template](https://docs.coopcloud.tech/maintainers/maintain/#maintenancemd-template)
|
||||
described in the Co-op Cloud maintainers' docs.
|
||||
|
||||
All contributions should be made via a pull request so that quality and
|
||||
consistency stay something others can rely on.
|
||||
|
||||
## Maintainers
|
||||
|
||||
Everyone can apply to be a recipe maintainer.
|
||||
Simply add your self to the list in the README.md and open a new pull request
|
||||
with the change.
|
||||
|
||||
## Maintainer Responsibilities
|
||||
|
||||
This recipe commits to the following, which is tighter than the floor set by
|
||||
Resolution 025 (stable-recipe category). However, these timelines are
|
||||
best-effort, so we aim for them as good as possible:
|
||||
|
||||
- Respond to PRs / issues within 3 working days
|
||||
- Apply security patches within 1 week of disclosure
|
||||
- Ship patch / minor image updates within 2 weeks of upstream release
|
||||
- Adopt major Nextcloud version updates within 1 release cycle of upstream
|
||||
EOL of the previous major (see below)
|
||||
- Keep documentation current
|
||||
|
ineiti marked this conversation as resolved
Outdated
|
||||
|
||||
In order to meet these responsibilities each maintainer:
|
||||
|
||||
- Watches the repository so notifications arrive
|
||||
- Keeps an eye on [Renovate](./renovate.json) updates and helps shepherd them through
|
||||
- Has a working contact (Matrix handle or email) reachable by the others
|
||||
|
||||
## Release cadence
|
||||
|
||||
The intent is to **track Nextcloud's own release schedule** rather than invent
|
||||
our own. In practice this means:
|
||||
|
||||
- **Patch releases (e.g. `32.0.x`)**: published to this recipe shortly after
|
||||
upstream, ideally within 1 week. `chore(deps)` opens the PRs; a maintainer
|
||||
reviews the release notes and Nextcloud's issue tracker, and merges the PR
|
||||
if it is OK.
|
||||
- **Minor releases**: same flow as patch releases, but one of the maintainer
|
||||
tests it on their own instance before merging.
|
||||
- **Major releases (e.g. `32 → 33`)**: not adopted on day one. We wait for the
|
||||
first one or two upstream patch releases of the new major to land
|
||||
|
ineiti marked this conversation as resolved
Outdated
dannygroenewegen
commented
If we are deploying a patch release only quickly against a test instance, I don't think that adds much value compared to the tests that Nextcloud itself already does. If the patch image update is done by Renovate, the risk of making a configuration error is pretty small. I would propose that, for a patch release, a maintainer does a quick review (release notes and Nextcloud's issue tracker?) and then releases the new version. A patch can always introduce a bug that affects someone, but the same patch could also fix a bug for someone else and security issues. Overall, I think it's better to have a low threshold for releasing patch updates. The next line for Minor release should then be updated to something like a more thorough review of the release notes and a test upgrade? If we are deploying a patch release only quickly against a test instance, I don't think that adds much value compared to the tests that Nextcloud itself already does. If the patch image update is done by Renovate, the risk of making a configuration error is pretty small.
I would propose that, for a patch release, a maintainer does a quick review (release notes and Nextcloud's issue tracker?) and then releases the new version.
A patch can always introduce a bug that affects someone, but the same patch could also fix a bug for someone else and security issues. Overall, I think it's better to have a low threshold for releasing patch updates.
The next line for Minor release should then be updated to something like a more thorough review of the release notes and a test upgrade?
|
||||
(typically 1–2 months) before promoting it here, to avoid passing the
|
||||
early-adopter cost to operators. Major bumps get their own PR with release
|
||||
|
ineiti marked this conversation as resolved
Outdated
dannygroenewegen
commented
Proposal for Major release:
Proposal for Major release:
- Upgrade should be tested by at least two maintainers, preferably on a production-like instance, not just a fresh instance.
- Before the Major release, we first release a new Minor version that sets the image tag for Nextcloud to e.g. nextcloud:32-fpm. This allows anyone not willing to upgrade to the next major version to stay on the current version while still getting minor and patch releases for that version. This recipe release will be less predictable; a redeploy could pull an updated Nextcloud image. If you don't want that unpredictability, you can still use the previously released recipe with a specific 32.x.x image)
- Release the Major update with the image tag set to the latest specific release, e.g. nextcloud:33.0.2-fpm
ineiti
commented
Can you please explain how tagging with Can you please explain how tagging with `nextcloud:32-fpm` helps in that case? I'm not yet very fluent in how abra works with upgrades.
dannygroenewegen
commented
The current recipe version is 13.0.1+32.0.3-fpm, which deploys the 32.0.3-fpm image of Nextcloud. If we now decide to move to Nextcloud 33, we would release a recipe with the tagged version 14.0.0+33.0.5-fpm. But if for whatever reason you can't move to version 33 yet, you'll have to stay on recipe version 13.0.1+32.0.3-fpm, and you're missing out on all the bugfixes and security updates in 32.0.4-32.0.12. Version 32 will still receive updates for a few more months. I'm proposing to first release a recipe version 13.1.0+32-fpm. This version will have the nextcloud image tag set to nextcloud:32-fpm. On redeploy, Docker will pull the latest 32 image (currently 32.0.12), but after a reboot it should just keep the last image version that was deployed. So a redeploy is less predictable in the sense that it could pull a new 32.x.x image if that was released since the last deploy. (To be fair, I haven't fully tested this with abra, so there might be edge cases where it will or won't pull an updated image) Immediately after we release a recipe version 14.0.0+33.0.5-fpm with image tag nextcloud:33.0.5-fpm. So anyone just updating to the latest recipe version should not notice a difference. But if you want to stay on Nextcloud 32, you can choose between recipe 13.0.1+32.0.3-fpm for a fixed image version or recipe version 13.1.0+32-fpm to get the latest 32 image on redeploy. The current recipe version is 13.0.1+32.0.3-fpm, which deploys the 32.0.3-fpm image of Nextcloud. If we now decide to move to Nextcloud 33, we would release a recipe with the tagged version 14.0.0+33.0.5-fpm. But if for whatever reason you can't move to version 33 yet, you'll have to stay on recipe version 13.0.1+32.0.3-fpm, and you're missing out on all the bugfixes and security updates in 32.0.4-32.0.12. Version 32 will still receive updates for a few more months.
I'm proposing to first release a recipe version 13.1.0+32-fpm. This version will have the nextcloud image tag set to nextcloud:32-fpm. On redeploy, Docker will pull the latest 32 image (currently 32.0.12), but after a reboot it should just keep the last image version that was deployed. So a redeploy is less predictable in the sense that it could pull a new 32.x.x image if that was released since the last deploy. (To be fair, I haven't fully tested this with abra, so there might be edge cases where it will or won't pull an updated image)
Immediately after we release a recipe version 14.0.0+33.0.5-fpm with image tag nextcloud:33.0.5-fpm. So anyone just updating to the latest recipe version should not notice a difference. But if you want to stay on Nextcloud 32, you can choose between recipe 13.0.1+32.0.3-fpm for a fixed image version or recipe version 13.1.0+32-fpm to get the latest 32 image on redeploy.
ineiti
commented
OK, if I understand that correctly, you propose to create a "catch-all-future-updates" version, where the user can OK, if I understand that correctly, you propose to create a "catch-all-future-updates" version, where the user can `app deploy --force` and it will pull the latest minor/patch version of the previous major version. Sounds like a good hack! Thanks for the explanation.
|
||||
notes and an upgrade-path check.
|
||||
Before adding a major release, the following needs to be done:
|
||||
- at least two maintainers update one of their production instances to the
|
||||
new version
|
||||
- the previous release gets a last update pointing to the docker image
|
||||
versions nextcloud:xx-fpm, so that users can auto-update if they wish so
|
||||
- the new release is added to this repo
|
||||
- If people have the time it would be nice to create specially tagged versions
|
||||
for major releases, which reflect that this is 'bleeding edge' and has not
|
||||
been thoroughly tested.
|
||||
- **Co-installed components** (Talk HPB, OnlyOffice, Whiteboard, etc.) are
|
||||
bumped alongside or shortly after the matching Nextcloud release.
|
||||
|
||||
## Pull Requests
|
||||
|
||||
A pull request can be merged once it is approved by at least one maintainer.
|
||||
PRs opened by a maintainer need approval from another maintainer. With three
|
||||
maintainers this is workable; if the group shrinks, the rule should be
|
||||
revisited.
|
||||
|
||||
Approvals should ideally include a smoke test on a real instance for anything
|
||||
beyond a patch bump — Nextcloud upgrades have a long history of surprising us
|
||||
(see the [upgrade notes in `README.md`](./README.md#upgrading-nextcloud)),
|
||||
and silent CI is not enough.
|
||||
|
||||
## Becoming a maintainer
|
||||
|
||||
Everyone is welcome to apply:
|
||||
|
||||
1. Watch the repository so you get notifications.
|
||||
2. Open a pull request adding yourself to the `Maintainer` line in
|
||||
[`README.md`](./README.md) and to the list above.
|
||||
3. Once an existing maintainer merges the PR, you'll be added to the
|
||||
[nextcloud maintainers
|
||||
team](https://git.coopcloud.tech/org/coop-cloud/teams/nextcloud-maintainers)
|
||||
_(team to be created if it does not yet exist — TBD)_.
|
||||
|
||||
Stepping down is symmetrical: open a PR removing yourself, and flag it in
|
||||
the federation channels so the group can plan replacement before falling
|
||||
below the Res. 025 floor of one named maintainer.
|
||||
@@ -5,6 +5,7 @@
|
||||
Fully automated luxury Nextcloud via docker-swarm.
|
||||
|
||||
<!-- metadata -->
|
||||
* **Maintainer**: [@dannygroenewegen](https://git.coopcloud.tech/dannygroenewegen), [@ineiti](https://git.coopcloud.tech/ineiti)
|
||||
* **Category**: Apps
|
||||
* **Status**: 5
|
||||
* **Image**: [`nextcloud`](https://hub.docker.com/_/nextcloud), 4, upstream
|
||||
|
||||
I can join the maintainers team, but I cannot commit to these timelines. Can we rephrase all these deadlines to something like 'within a reasonable amount of time', or is someone else willing to commit to these timelines?
Tagging others from #57 that wanted to maintain: @stevensting @simon @Apfelwurm
I propose we keep the timeline, but add "according to best effort" or something like that. Having a timeline can also give an incentive to move the task up in the list of "voluntary project efforts". And, as none of us is paid for this, nobody will get fired over missing a deadline :)
So if we're a bunch of maintainers, I think 3 days is reasonable for a reply. Also, it's not about solving the issue, but at least advancing it a bit.
I'm not afraid of getting fired, but I do tend to take commitments seriously, so I don't want to commit to something I won't be able to keep up with. Starting this list with the fact that we aim for these deadlines is indeed a good middle ground.