Maintenance

[jplatte]

Hey @mladedav, @Turbo87 and @yanns (and everybody else).

I haven't been having a lot of fun maintaining axum for a while. I'm not planning to leave the project completely any time soon, but I do think scaling back my involvement would be a good thing for me.

However, I'm pretty sure that if I just do that without telling anybody, even more PRs / issues / discussions will just sit there without any response and I think that's a pretty awkward state of affairs.

So, I'd like to hear everybody's thoughts on this. Here are some of mine:

• Is anybody interested in scaling up their involvement?
  • Would anything be required for that to work? For example
    • More autonomy at the individual level?
    • A well-defined consensus mechanism when it's not obvious whether / how to address something?
• Should we do anything to reduce maintenance work?
  • We already have CI checks for a lot of things, I guess the only thing somewhat frequently pointed out by maintainers is changelog entries
    • I don't think "does this PR contain a changelog-worthy change" can be detected in CI
    • Could adjust the pull request template to have a checkbox for this, or similar, I guess?
  • Direct people elsewhere for asking questions rather than the Discussions section, because the questions there tend to only be answered by us maintainers?

[yanns]

Thanks for bringing this topic and be transparent about it.
I'm not sure if I would / could scale up my involvement.

Should we do anything to reduce maintenance work?

Some points here:

• the CI is often broken. I don't always know why. It'd be nice to have more consistent results.
• releases could maybe be automated, just by pushing a tag?

[jplatte]

About CI being broken, that's a good point. I think we should ideally pin a specific nightly and bump it manually from time to time. However, this needs a change to the cargo-public-api-crates, which I think still tries to use a nightly toolchain to gather rustdoc JSON. One option would be to add the GH actions scaffolding to that repo directly, and building the rustdoc JSON separately as part of that, as opposed to having cargo-public-api-crates call out to a cargo for which it doesn't know whether it supports (the right version of) rustdoc-json.

About releases, I'm not a big fan of handing crates.io keys to GitHub, though nowadays it's no longer as bad since crate-specific publish keys exist. Also this seems like a somewhat involved project to implement?

[yanns]

I think that crates.io now supports OIDC to github to avoid using keys.

[Turbo87]

think that crates.io now supports OIDC to github to avoid using keys.

yeah, trusted publishing should be relatively straight-forward to set up, I think. It would probably make sense to have to have a workflow per package, that only triggers on pushed tags with the right package name prefix. Not sure if the same is easily possible as dedicated jobs within the same workflow, but worth investigating.

the CI is often broken.

do you have examples for this? I usually try to pin as many things in CI as possible and then rely on https://docs.renovatebot.com/ to explicitly update stuff via pull requests. I've rarely had CI randomly break since I adopted that workflow.

[mladedav]

I think it's mostly that there are checks against stable/beta so when new warn-by-default clippy or rustc lints are added, the CI starts failing.

[jplatte]

Pinging some other people who I know have maintenance experience, and have contributed before: @tottoto @GlenDC

Would love to hear any thoughts you have on the above, even if you're not interested in adding "axum maintenance" to your plates :)

[GlenDC]

I think most of what I’d suggest off the top of my head has already been mentioned here in comments or replies.

I’m happy to help with maintaining Axum. That said, its popularity brings some common challenges — for example, contributors opening a PR and then not returning to finish it. In cases like that, maintainers need a clear policy: how do we escalate, and what’s the end point? Do we close it, or take it over the finish line ourselves?

The next point relates to what @mladedav mentioned in his comment. You, Jonas, and others on the core team may have slightly different approaches — some important, others more stylistic or philosophical. As a new maintainer on a project I don’t own, it’s tricky to know when a PR is truly ready to merge. I’d like to avoid situations where I merge several PRs I believe are fine, only to find there’s post-merge consensus that certain things should have been done differently. It’s less of a problem pre-release, but it can still cause friction. Perhaps I’m overthinking it, but it’s worth aligning on.

In any case, I’m glad to help if you’ll have me. I can dedicate some time each week to help PRs over the finish line, answer tickets, or handle whatever else you think would be most useful.

[jplatte]

In any case, I’m glad to help if you’ll have me.

Thanks! Invited you :)

[tottoto]

I'm not sure how much I could contribute, I'd be glad to help if you prefer. If adding to the existing discussions, I think one option which could be considered is to reduce functionality as a way to improve maintainability with the trade off of resulting to providing fewer functionalities. For example, if the release cycle of one public dependent library doesn't fit that of the Axum, and the maintenance costs become a burden compared to providing that functionality, then the option of reducing functionality might be considered. Regarding the cases where updates are not made for some time after reviews, the maintenance costs might be reduced by automating of the response with some tools.

[jplatte]

Thanks for your thoughts. Regarding reducing functionality, I just opened #3442 which I really wanted to do for a while already.

I don't think automated pings on PRs would help that much, and I haven't seen it done elsewhere in a nice way (I hate stale-bot with a passion, but maybe because I've only seen it close still-relevant issues, it could be useful for PRs?).

[mladedav]

Yeah, thanks for being open about this!

I'd like to scale up my involvement, though even now there are PRs waiting for me. But I'll try to manage my time a bit better and push a few of the open PRs over the finish line.

I guess we sometimes lack a consensus mechanism and everyone at times defaults to "I'd slightly prefer A, but if you slightly prefer B, let's do that." I'm not really sure what to do about that, I mostly did what I just described because I take you as the authority here having several years more of experience and insight into the history and direction of the project.

[jplatte]

Regarding consensus, are all of you active on Discord? Maybe having an axum-internals / axum-dev channel for maintainer discussion (that doesn't need to happen "in front of" contributors) would be helpful?

[yanns]

Yes this could be useful.

[Turbo87]

Is anybody interested in scaling up their involvement?

I'm pretty busy with crates.io development and maintenance, so I can't commit to much more at this time. I'm happy to comment on and review stuff that I'm familiar with though, if pinged.

Also, sorry for the late reply. I had been on vacation for a couple of weeks 😅

We already have CI checks for a lot of things, I guess the only thing somewhat frequently pointed out by maintainers is changelog entries

On other projects I've been using https://git-cliff.org/ in a way that lists all the pull requests that went into a release, but grouped by pull requests labels. Compared to commit-message-based changelog generators, this has the advantage of being able to relabel commits/PRs after they have been merged. Caveat: I haven't tried this out on a monorepo like this, but I think it should be able to handle this too, if configured correctly.