Proposing a MAINTENANCE file #81

2026-05-22T10:24:44Z

ineiti commented

2026-05-22 10:24:44 +00:00

Cobbled together a file with the help of Claude.
I did re-read all of it, manually edited some parts,
and asked for modifications.

Cobbled together a file with the help of Claude. I did re-read all of it, manually edited some parts, and asked for modifications.

ineiti requested review from decentral1se 2026-05-22 10:24:52 +00:00

ineiti referenced this pull request

2026-05-22 10:26:02 +00:00

Call for maintainers #57

3wordchant commented

2026-05-28 16:44:48 +00:00

@ineiti I like the reference to Nextcloud's own release schedule!

dannygroenewegen requested changes 2026-06-02 14:02:10 +00:00

Dismissed

MAINTENANCE.md Outdated

						
				@@ -0,0 +31,4 @@

				This recipe commits to the following, which is tighter than the floor set by

				Resolution 025 (stable-recipe category):

				- Respond to PRs / issues within 3 working days

dannygroenewegen commented

2026-06-02 13:33:59 +00:00

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 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

ineiti commented

2026-06-05 07:58:06 +00:00

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 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.

dannygroenewegen commented

2026-06-09 07:23:49 +00:00

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.

ineiti marked this conversation as resolved

MAINTENANCE.md Outdated

						
				@@ -0,0 +51,4 @@

				- **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, deploys against a test instance, and tags.

dannygroenewegen commented

2026-06-02 13:47:31 +00:00

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?

👍 1

ineiti marked this conversation as resolved

MAINTENANCE.md Outdated

						
				@@ -0,0 +53,4 @@

				  upstream, ideally within 1 week. `chore(deps)` opens the PRs; a maintainer

				  reviews, deploys against a test instance, and tags.

				- **Minor releases**: same flow as patch releases.

				- **Major releases (e.g. `32 → 33`)**: not adopted on day one. We wait for the

dannygroenewegen commented

2026-06-02 14:00:10 +00:00

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

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

2026-06-05 08:00:12 +00:00

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.

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

2026-06-09 09:02:56 +00:00

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

2026-06-13 16:43:36 +00:00

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.

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.

ineiti marked this conversation as resolved

ineiti commented

2026-06-14 07:59:27 +00:00

@dannygroenewegen updated the MAINTENANCE.md file with your suggestions. Let me know if I missed anything, please.

👍 1

dannygroenewegen approved these changes 2026-06-14 18:53:13 +00:00

ineiti commented

2026-06-15 05:46:15 +00:00

So who should be in the initial maintainers list? I'm happy to be on it. Shall I add you, too, @dannygroenewegen ? @3wordchant ?

👍 1

3wordchant commented

2026-06-15 20:59:34 +00:00

I would prefer not to, sending y'all good luck though

ineiti commented

2026-06-16 20:05:37 +00:00

Pinging the last couple committers to this recipe - do you want to appear as a maintainer?

@carla @decentral1se @moritz @oxaliq @simon @iexos @p4u1 @Apfelwurm @ammaratef45

Also, one of you will have to add me to the repo so I have write access :)

Pinging the last couple committers to this recipe - do you want to appear as a maintainer? @carla @decentral1se @moritz @oxaliq @simon @iexos @p4u1 @Apfelwurm @ammaratef45 Also, one of you will have to add me to the repo so I have write access :)

ammaratef45 commented

2026-06-16 20:17:15 +00:00

I would prefer not to, sending y'all good luck though

I +1 this, wish I had capacity

> I would prefer not to, sending y'all good luck though I +1 this, wish I had capacity

carla commented

2026-06-17 07:15:24 +00:00

@moritz @simon and me, we are trying to maintain the recipe as part of our workflow at our it collective. But if you have the capacity and you feel good with the list of maintainers from now, we are happy if you take care of it :) We can put more work on other recipes than. Likewise we would not be able to keep up with the responsibilities in the maintenance file (3 days for PRs eg). So as I said: if you feel comfortable we do not need to be listed :)

ineiti commented

2026-06-17 20:40:32 +00:00

@moritz @simon and me, we are trying to maintain the recipe as part of our workflow at our it collective. But if you have the capacity and you feel good with the list of maintainers from now, we are happy if you take care of it :) We can put more work on other recipes than. Likewise we would not be able to keep up with the responsibilities in the maintenance file (3 days for PRs eg). So as I said: if you feel comfortable we do not need to be listed :)

I'm actually realising that my way of working might not be possible here: toolshed/organising#678 - if I'm not allowed to use LLMs when working on the recipes or tools, I won't have the necessary time to participate in this wonderful project :( Which of course I understand and will respect. But then I'd have to remove myself from the README.md, and I'll add you :)

> @moritz @simon and me, we are trying to maintain the recipe as part of our workflow at our it collective. But if you have the capacity and you feel good with the list of maintainers from now, we are happy if you take care of it :) We can put more work on other recipes than. Likewise we would not be able to keep up with the responsibilities in the maintenance file (3 days for PRs eg). So as I said: if you feel comfortable we do not need to be listed :) I'm actually realising that my way of working might not be possible here: https://git.coopcloud.tech/toolshed/organising/issues/678 - if I'm not allowed to use LLMs when working on the recipes or tools, I won't have the necessary time to participate in this wonderful project :( Which of course I understand and will respect. But then I'd have to remove myself from the README.md, and I'll add you :)

ineiti force-pushed maintenance.md from bc7a2aa62b to 3eab656a84

2026-07-03 13:07:34 +00:00

Compare

ineiti commented

2026-07-03 13:18:21 +00:00

OK, looks like currently only @dannygroenewegen and me want to maintain this recipe. Also, the decision for/against/how wrt LLMs seems to take some time. In the meantime I link to the draft of the AI Policy I cobbled together (w/o an LLM...) in the MAINTENANCE.md.

So if @moritz @simon @carla agree with this last change, I only need to convince somebody to give me actual access to the /coop-cloud organisation... @decentral1se is that you?

Once somebody signs me up, I'm OK with merging this PR, and I'll be happy to help move nextcloud to version 34...

OK, looks like currently only @dannygroenewegen and me want to maintain this recipe. Also, the decision for/against/how wrt LLMs seems to take some time. In the meantime I link to the draft of the [AI Policy](https://git.coopcloud.tech/c4dt/ai-policy) I cobbled together (w/o an LLM...) in the MAINTENANCE.md. So if @moritz @simon @carla agree with this last change, I only need to convince somebody to give me actual access to the /coop-cloud organisation... @decentral1se is that you? Once somebody signs me up, I'm OK with merging this PR, and I'll be happy to help move nextcloud to version 34...

carla commented

2026-07-06 12:00:48 +00:00

Hey !
Sorry for the late response, yes as you see we also have few capacities in these days. So thank you for taking care of the recipe :)

Hey ! Sorry for the late response, yes as you see we also have few capacities in these days. So thank you for taking care of the recipe :)

👍 1

ineiti commented

2026-07-18 18:38:32 +00:00

I asked in various channels how to get write access to the coop-cloud/nextcloud repo, but so far I have no reply. So I started doing some development here:

https://git.coopcloud.tech/c4dt/nextcloud

It updates to nextcloud-v34, including EuroOffice. I tried it out on my test and demo accounts, and works fine. The one special thing I did was to put EuroOffice directly in the main recipe, instead of adding a separate recipe like OnlyOffice.

I asked in various channels how to get write access to the coop-cloud/nextcloud repo, but so far I have no reply. So I started doing some development here: https://git.coopcloud.tech/c4dt/nextcloud It updates to nextcloud-v34, including EuroOffice. I tried it out on my test and demo accounts, and works fine. The one special thing I did was to put EuroOffice directly in the main recipe, instead of adding a separate recipe like OnlyOffice.

ammaratef45 commented

2026-07-19 00:29:13 +00:00

hi @ineiti
I've created a team (nextcloud-maintainers) that has administrative access to the repo and added you as a member, let me know if it works as expected

hi @ineiti I've created a team (nextcloud-maintainers) that has administrative access to the repo and added you as a member, let me know if it works as expected

ineiti commented

2026-07-20 07:35:26 +00:00

Hi @ammaratef45,

thanks a lot. Before I merge, I would like to get the CI working, but I don't understand the error given in the CI. First I thought it's because I'm not in the team, but now I can "Create merge commit", but I still get the following error:

latest: Pulling from coop-cloud/stack-ssh-deploy
Digest: sha256:fc1fa69bea5528db7ba184297735ac1bbd278720910e4cb1f502de9aee14e228
Status: Image is up to date for git.coopcloud.tech/coop-cloud/stack-ssh-deploy:latest
--- start ssh-stack-deploy ---
--- start ssh key load ---

Hi @ammaratef45, thanks a lot. Before I merge, I would like to get the CI working, but I don't understand the error given in the CI. First I thought it's because I'm not in the team, but now I can "Create merge commit", but I still get the following error: ``` latest: Pulling from coop-cloud/stack-ssh-deploy Digest: sha256:fc1fa69bea5528db7ba184297735ac1bbd278720910e4cb1f502de9aee14e228 Status: Image is up to date for git.coopcloud.tech/coop-cloud/stack-ssh-deploy:latest --- start ssh-stack-deploy --- --- start ssh key load --- ```

ammaratef45 commented

2026-07-20 13:14:05 +00:00

Looks like this is why?

		nextcloud/.drone.yml
		Line 13 in 19e7fbb648
	
				        from_secret: drone_ssh_swarm_test

@3wordchant @decentral1se would either of you have tribal knowledge on this? the build used to work up until 10 months ago

Looks like this is why? ![Screenshot 2026-07-20 at 6.08.10 AM.png](/attachments/65513469-69c2-4181-86cb-78e5e4804704) https://git.coopcloud.tech/coop-cloud/nextcloud/src/commit/19e7fbb648592f817886478c87a751b5d3eb1aa2/.drone.yml#L13 @3wordchant @decentral1se would either of you have tribal knowledge on this? the build used to work up until 10 months ago

Screenshot 2026-07-20 at 6.08.10 AM.png

242 KiB

ineiti commented

2026-07-20 15:02:26 +00:00

This might not be available anymore:

kind: pipeline
--
name: deploy to swarm-test.autonomic.zone

On CC | General, @kawaiipunk just wrote about autonomic.zone, so I contacted her. Let's see if that helps unblock this...

This might not be available anymore: ``` kind: pipeline -- name: deploy to swarm-test.autonomic.zone ``` On `CC | General`, @kawaiipunk just wrote about autonomic.zone, so I contacted her. Let's see if that helps unblock this...

ineiti commented

2026-07-20 15:29:32 +00:00

Thanks a lot @kawaiipunk for your quick reply on matrix:

remove that part and hang on for the new server

She propose that there might be a new VPS for swarm-test.autonomic.zone, but in the meantime it's better to go on without it.

Thanks a lot @kawaiipunk for your quick reply on matrix: > remove that part and hang on for the new server She propose that there might be a new VPS for swarm-test.autonomic.zone, but in the meantime it's better to go on without it.

ineiti added 4 commits 2026-07-21 05:59:44 +00:00

Proposing a MAINTENANCE file 8ce1b9cf30

Cobbled together a file with the help of Claude.
I did re-read all of it, manually edited some parts,
and asked for modifications.

Adding suggestions from @dannygroenewegen 10fdbc92b4

Adding maintainers to README.md 6e6c235acd

README improvements 38920ae3de

ineiti force-pushed maintenance.md from c81c39ff42 to 38920ae3de

2026-07-21 05:59:44 +00:00

Compare

ineiti commented

2026-07-21 06:00:51 +00:00

@ammaratef45 all ready now. Last question: what is the usual merge done here? Merge, rebase, squash, ...?

ineiti added 1 commit 2026-07-21 06:08:59 +00:00

Removing last TBDs 38c426178a

ineiti commented

2026-07-21 06:11:06 +00:00

@ammaratef45 can you also add @dannygroenewegen to the https://git.coopcloud.tech/org/coop-cloud/teams/nextcloud-maintainers team, please?

carla commented

2026-07-21 06:16:49 +00:00

Hey @ineiti !
Thanks for pushing that forward and taking care of it!
Talking about moving towards Nextcloud 34: There was also someone texting me on matrix who would like to help testing Nextcloud recipe updates (especially towards version 34). So let me know if you want the contact. Maybe you can let us know when you plan the upgrade to version 33/34 :)

Hey @ineiti ! Thanks for pushing that forward and taking care of it! Talking about moving towards Nextcloud 34: There was also someone texting me on matrix who would like to help testing Nextcloud recipe updates (especially towards version 34). So let me know if you want the contact. Maybe you can let us know when you plan the upgrade to version 33/34 :)

ineiti commented

2026-07-21 11:41:23 +00:00

Hey @ineiti !
Thanks for pushing that forward and taking care of it!
Talking about moving towards Nextcloud 34: There was also someone texting me on matrix who would like to help testing Nextcloud recipe updates (especially towards version 34). So let me know if you want the contact. Maybe you can let us know when you plan the upgrade to version 33/34 :)

Hi @carla - yes, please, let us test it out. I'm currently running two nextcloud instances on v34, both with EuroOffice enabled:

#91

However, I had to change how remote recipes are handled in abra, mainly because I want to have one github repo with all my config, but on multiple machines. Not sure how well it works without my vibecoded PR here:

toolshed/abra#870

Let's discuss it in the PR #91

> Hey @ineiti ! > Thanks for pushing that forward and taking care of it! > Talking about moving towards Nextcloud 34: There was also someone texting me on matrix who would like to help testing Nextcloud recipe updates (especially towards version 34). So let me know if you want the contact. Maybe you can let us know when you plan the upgrade to version 33/34 :) Hi @carla - yes, please, let us test it out. I'm currently running two nextcloud instances on v34, both with EuroOffice enabled: https://git.coopcloud.tech/coop-cloud/nextcloud/pulls/91 However, I had to change how remote recipes are handled in abra, mainly because I want to have one github repo with all my config, but on multiple machines. Not sure how well it works without my vibecoded PR here: https://git.coopcloud.tech/toolshed/abra/pulls/870 Let's discuss it in the PR #91

👍 1

ammaratef45 commented

2026-07-22 03:32:48 +00:00

@ammaratef45 can you also add @dannygroenewegen to the https://git.coopcloud.tech/org/coop-cloud/teams/nextcloud-maintainers team, please?

done

> @ammaratef45 can you also add @dannygroenewegen to the https://git.coopcloud.tech/org/coop-cloud/teams/nextcloud-maintainers team, please? done

ammaratef45 commented

2026-07-22 03:33:43 +00:00

@ammaratef45 all ready now. Last question: what is the usual merge done here? Merge, rebase, squash, ...?

as the maintainers you get to decide :)

my personal preference would be rebase then fast forward

> @ammaratef45 all ready now. Last question: what is the usual merge done here? Merge, rebase, squash, ...? as the maintainers you get to decide :) my personal preference would be rebase then fast forward

ineiti merged commit 38c426178a into main

2026-07-22 08:12:08 +00:00

ineiti deleted branch maintenance.md

2026-07-22 08:12:16 +00:00

ineiti commented

2026-07-22 08:12:53 +00:00

as the maintainers you get to decide :)

As old person I'm trying to respect traditions, hoping the youngsters will respect mine, too :)

my personal preference would be rebase then fast forward

Thanks - did that now.

> as the maintainers you get to decide :) As old person I'm trying to respect traditions, hoping the youngsters will respect mine, too :) > my personal preference would be rebase then fast forward Thanks - did that now.

❤️ 1

Sign in to join this conversation.

5 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: coop-cloud/nextcloud#81

Allow edits from maintainers