add MAINTAINERS.md #61
Reference in New Issue
Block a user
No description provided.
Delete Branch "maintainers"
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?
This is just a proposal, please comment or propose changes :)
@ -0,0 +4,4 @@## Maintainers- @p4u1 [Klasse & Methode](https://klasse-methode.it)Add your self here :)
Maybe we can be more explicit and say that
@p4u1is the Gitea handle?I have linked my gitea profile now where I linked to matrix and co.
tysm 🙏
@ -0,0 +1,25 @@# Traefik Recipe MaintenanceOnly recipe maintainers can push to main / merge pull requests. This is to ensure a certain quality / consistency, that others can rely on.I would just go straight for "only merge when reviewed by another" workflow. Pushing to main is cool and all but we all make mistakes and if we do want stability, we need more eyeballs before a change lands. Idk if this is controversial but while we're here.... 🤸
@ -0,0 +8,4 @@## Maintainer ResponsibilitiesA recipe maintainer has the following responsibilities:Should we add the following?
Has renovate enabled for automatic update PRs (so that becomes standard). We might need to document how to update / merge these PRs with label changes.
Is not responsible for solving the issues of others (if it falls outside of update work) but is responsible to triage the issue, e.g. "a fix would look like this, PRs welcome, byeeeee".
@ -0,0 +17,4 @@## Merge rulesA pull request can be merged if it is approved by at least one maintainer.A maintainer can push directly to main for small changes and should make a pull request for larger changes like major updates.I'm fine with it but I'd prefer to abolish "push to main" for stability purposes.
See #61 (comment).
Tiny drive-by comment that, as well as this awesome stuff, it'd be great to reflect this in
README.mdas well. I did my best to interpret the Resolution for coop-cloud/mastodon here:23a71ea65bI have pushed an update and tried to include @decentral1se and @3wordchant suggestions
👏
I'm still worried that dealing with doing update work won't happen on time without mandating #61 (comment) but in practice, I guess people will figure it out.
Thanks!
@decentral1se I made another commit, that should resolve your renovate comment:
3ae4d8f889First of all, love this! 💟
My only Q: why are the expectations here wildly off from the resolution doc?
E.g.
I think a month is too long, but is a same-day turnaround realistic?
I'm keen to hear what y'all think 😊
@pharaohgraphy I see Resolution 025 as establishing a minimum; personally it seems fine if recipe maintainers want to commit (haha) to higher standards above those.
I think it is a good idea to set up the expectations high for such a critical piece of software like traefik :)
My take on this is, that as soon as we implement renovate, it is really only one click (or api call) for any one of the maintainers to merge security critical updates and i guess therefore we just have to make sure that there are enough people taking on those critical recipes. No matter of how we set our expectations, it would be pretty bad if one of the most exposed services in our ecosystem is exploitable for longer than it needs to be. But its tbd how that works out in practice, as i know that i'm not having the greatest consistency in chore management :D
As a coopcloud noob I would really appreciate this as a way to know what to expect from recipe-upgrades. And also as a way to know what would be required as a maintainer.
My only concern would be that this should apply to all recipes, and because of this it might be more efficient to put this in coopcloud docs or some other more central place. Not to say this shouldn't be merged, just a thought.
I think I addressed all actionable comments. I will just merge now and we will se how it will go from here. Everyone is welcome to add yourself as a maintainer and also update the maintenance document :)