Remove -Dwarnings from clippy run

[Nercury]

Rationale: more annoying than necessary.

[MarijnS95]

That defeats the purpose of running clippy in CI doesn't it?

(In reply to your "no description provided" PR)

I appreciate the feedback; I don't have much time to sit waiting though or debugging why clippy is failing only on specific builds. I see the warning as absolutely non-critical for a lib this small.

[Nercury]

@MarijnS95 I have sent you an invite for owner of this crate at crates.io. I may not be around forever, so the mo maintainers the better.

[MarijnS95]

That is unfortunate to hear, and unfortunate to see this merged so plainly.

My experience with clippy has been the complete inverse. It has always pointed out useful code smells or inconsistencies that are trivial to fix and make the code so much nicer to read and maintain.

More importantly it has always been the first line of defence against external contributions in the crates that I maintain. By forcing contributors to ensure the CI succeeds first by fixing most obvious code smells pointed out by clippy, I save myself a whole bunch of time and pain dredging through their "inventions" (and unused debug remnants).

In this specific case the linter isn't "failing only on specific builds" but is suggesting a more natural way to write format strings, aligned with the MSRV that this project sets.

In summary, because of the above, I refrain from (co)maintaining crates that don't have or desire a complete CI, including clippy steps (how we tune it for specific lints is up for debate) - I'm totally happy to set things up and maintain newer Rust versions with improved linting along the way. That is why I have not yet accepted your crates.io requests (even if they were aimed at reducing the bus factor, not necessarily co-maintaining the code if I understand your request correctly).

[Nercury]

I am not against clippy. It can be reintroduced with a simple PR. It was either me doing the maintenance and publishing PRs that were sitting there for months, or just doing nothing.

[Nercury]

Ok, I thought about this and I realize my mistake. I thought it was just a silly clippy check, and did not expect these implications.
I should not have dismissed your comment. That action showcased disrespect for your opinion and now you are pissed. More than that, it might have hinted that contributions to this crate are not valued.
For the former, I am sorry. I was in a rush and it won't happen again.
For the latter, your contributions are very valued; I value your attention to detail in PR and PR reviews. Frankly, I don't do that job well and sometime might trust people too much. That's why I have sent you those invites; no one was taking care of PRs for months, and given your recent involvement I thought you would appreciate not having to ping me for a crate release.

[MarijnS95]

That is good to hear, I'll reintroduce it in a followup (with aforementioned clippy fixes) while removing max_level.

I did not feel disrespected by your actions, and if it sounded like that, my apologies. It seems like we have just had wildly different experiences while maintaining Rust crates over the past years. I've completely lost all trust and faith in external contributors, which they need to earn back over time by the quality of their PRs as proof - and I'll be really strict in validating their quality and completeness (down to the nitty little details) so that I simply don't have to look back at things after merging (the ndk crate is a great example for this).

My recent involvement in reviews stems from the fact that I use this niche little crate in quite a few places and value the things it achieves; but at the same time wanted to prevent regressions slipping into the next release through critical reviews. And because of receiving notifications after this repo was migrated to rust-mobile: I'll end up curiously skimming a PR and end up with tens of comments before realizing that I'm scrutinizing it after being triggered 🙂

In that sense I don't think that PRs being open for months with zero followup or feedback warrant an automatic merge and release. But I'm perhaps biased because they directly impede the fixes I was planning around .with_max_level() 😅

I have accepted your invites now, though cannot commit to any form of consistent maintenance. My day-to-day has been too "unstable" for that and most crates/repo's I maintain have already suffered from that. I'll randomly be around - all over the place - though 🎉. And I'm notoriously bad at timely/progressive releases; typically waiting around to collect way too many changes before making one (which is sometimes A Good Thing™️, after previously catching a lot of flak for quickly and accidentally releasing many breaking changes / major bumps, causing lots of ecosystem churn). For the bigger repositories GitHub Milestones are awesome at this: they help me track all the important issues/PRs I need to address before committing to the next breaking release 🥳

[Nercury]

Hey, the invite is by no means an obligation. I figure multiple sporadically available contributors are better than one ;)

[MarijnS95]

And I wasn't seeing this as an obligation either :) - just being clear on what I can offer.

This crate definitely doesn't need a lot of attention anyway after initially getting all the details right. There's barely ever new API, and probably only sporadically a bugfix or a few little "Rust-isms" to "clean up" following newer clippy lints :)