generated from coop-cloud/example
Recipe maintainership #38
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally posted by @nicksellen in #37 (comment)
@nicksellen @ammaratef45 the process is still coming together, I think the most coherent is Traefik's, details here: coop-cloud/traefik#60
Personally I would definitely like to adopt the same model where only maintainers can merge PRs.
And I would definitely be open to you joining as maintainers @ammaratef45 @nicksellen.
@benjaminlyng what do you think?
And actually on reflection I'm more than happy dropping out as a maintainer and leaving it to you 3 😅
👉 https://docs.coopcloud.tech/maintainers/maintain/ 👈
Thanks for offering @3wordchant but I'll pass on being a maintainer for the mastodon recipe for now, I have few other recipes that I would rather focusing on and don't have other maintainers
Oh wow how did I miss / forget about this, incredible.
@benjaminlyng what are your thoughts on us copypasting the Traefik
MAINTENANCE.mdand fiddling the permissions as described on that page?And @nicksellen would you like to join the party?
Yes, would be happy to be added.
One point I would like to get clearer on is the release process. My last two PRs were completed and merged, but I did not know if I should do a release.
One of the PRs would need an entry added in the releases notes, but as it wasn't being released at that moment, I didn't have a version number to use for the release note file.
For the traefik PR template it says to add a release note -> https://git.coopcloud.tech/coop-cloud/traefik/src/branch/master/.gitea/PULL_REQUEST_TEMPLATE.md and then links to this page to explain about release notes https://docs.coopcloud.tech/maintainers/upgrade/#creating-new-release-notes where it's just a todo item to document it.
It's up to yourselves as new maintainers 😄 Before it was just cowgirl release mode whenever anyone had time.
You can throw everything in a
nextfile: docs.Docs patches welcome! Didn't get to finish it yet 🤸♀️ In general, we notice that those things are common pitfalls for contributors and cause breakage on deploy but we just need to all build up the habit when doing maintenance work. Please feel free to adapt / change 🥇
OK @nicksellen I heard from Benjamin,
$life_stuffongoing, will rejoin when possible. So I think please go ahead and submit a PR to add yourself to the README! (And for a million bonus points, copypastingMAINTENANCE.mdhere.Hi! Trying to ease back into the world. Welcome abord @nicksellen! Iv'e only just volunteered as a maintainer and still haven't found my way around it. Actually i'd be more comfortable if I wasn't a maintainer and that there was a more gitops-ish workflow where I could create a PR and everything relating to releases was automatic from there.
But that's another discussion.
Again welcome!
We're all discovering this maintainer process right now together, so please open issues and draw up proposals, docs patches, etc. It would be really appreciated @benjaminlyng! We need to make being a maintainer as simple and straightforward as possible for taking care of the entire config commons present and future, so now is the time to have that discussion 🙃 More general issues are usually opened up here: https://git.coopcloud.tech/toolshed/organising/issues