serde
serde copied to clipboard
serde-rs
Maintenance status of serde
Hi!
It seems to me like serde is a bit low on maintenance manpower. @dtolnay seems to be the only person reviewing PRs, but quite a few are still open after months without any feedback from a maintainer and many recent issues also seem to have gotten no maintainer attention at all. Same goes for the serde website repository.
I'm not trying to say that anybody should feel bad for that, that's just the way things go. However, I want to ask whether you (the maintainers) have this on your mind and have anything in mind to improve the situation.
@jplatte I'm just going to leave this here for you: https://blog.burntsushi.net/foss/
I have to say I'm consistently amazed by pretty much everything that @dtolnay has turned his hand to at the moment. He's doing brilliant work - I hope he keeps in this creative zone as I honestly can't wait to see what he turns his hand to next.
(If you want to lend a hand on Serde, just ask what you can do to help.)
I'm just going to leave this here for you: https://blog.burntsushi.net/foss/
@gilescope Already read that :)
I have to say I'm consistently amazed by pretty much everything that @dtolnay has turned his hand to at the moment. He's doing brilliant work - I hope he keeps in this creative zone as I honestly can't wait to see what he turns his hand to next.
I agree! And I've already tried to help – that's the reason I've opened this issue. I've got an open PR on this repo and one on the website repository, but both haven't gotten any feedback. Additionally, I've talked to @dtolnay about other potential improvements to serde over at https://github.com/serde-rs/serde/issues/1510 (last two comments), but haven't got any feedback since my last comment mid-december.
I think what you are observing is that mature projects naturally become increasingly selective about feature work over time.
Serde 1.0 was released 3 years ago. If I were someone using Serde, and Serde were still jamming in more and more and more features throughout those 3 years with no sign of slowing, that would be far more concerning to me as far as the future of Serde than the current maintenance investment.
Regarding pull requests: this is sad but it takes a huge amount of time to do a good job explaining why not to make most changes, and also a lot of expertise. Among the few people who could do a good job of this, it is not among the most impactful ways that they could be contributing to the Rust community. We do accept PRs, especially ones that improve the codebase without introduce user-facing changes, so I would recommend not taking this as a sign of the project being ignored or abandoned.
Regarding maintainer attention to support issues: I don't see this changing; we can't guarantee everything gets attention as the community scales. Users are free to help each other but in reality just responding to issues isn't something that most people would get excited about doing.
@dtolnay I worked on the first PR because you wrote in the corresponding issue that you'd accept a PR for it. If you have changed your mind mind about that, I understand.
However I don't see how what you've written applies to my documentation improval PR ~~or my question in #1510 about what kind of non-feature work you're looking for~~ (this part has been resolved).
It would be great if the above was a paragraph in CONTRIBUTING.md - hopefully that way it could save any future disappointment and everyone might get a little bit more of what they want as efforts are channeled into sought after areas.
Sent with GitHawk
@gilescope I also have a PR open that hasn't gotten any feedback since november 2019 (https://github.com/serde-rs/serde/pull/1685). I don't believe it falls into the "I need explaining why I shouldn't do it" category, since it's a small (but important IMO) improvement, and a mere follow-up to, and a completion of, another one I made earlier and which was merged. So I don't really know what to do about it.
For quite some time, watching the project, creating several issues and offering several PRs, all of which are still unanswered, I want to return to the problem of maintaining the repository.
If you look at the project analytics from GitHub, you can see that the only active maintainer is @dtolnay, but he has not been paying time to the project lately. Perhaps he simply does not have enough time to engage in support, or even lost the motivation to engage in the project. Of course, this is the right of everyone and no one is obliged to do anything without payment or obey the requirements of doing something.
However, I will still ask you not to forget that, according to @dtolnay himself (can not find the link), serde is used in about 25% of Rust projects. serde is an important part of the infrastructure, so widespread that it has become a de facto standard that it does not allow "to simply use something else", as they like to advise in such cases.
serde deservedly deserved its place in the ecosystem, but you need to remember that with great strength comes great responsibility, which means that the community cannot and should not allow the project to stagnate, which is apparently now happening :(.
To correct the situation, I suggest that the Rust team take care of the project in order to revive it and begin accept new PRs for fixing the old problems, which have accumulated a lot. Unfortunately, I don't know who will be addressed specifically, which people reconcile decisions, but I think these people will be able to help:
- @alexcrichton
- @killercup
I hope that in my message no one will choose any charges and all of us will try to do reasonably and prevent the death of the project.
I think what you are observing is that mature projects naturally become increasingly selective about feature work over time.
That would be a good explanation for lack of active development by core contributors but not PRs fixing important issues, not getting any attention. The problem is that if maintainers don't have time to look into PRs for months, the chances of bringing in new maintainers over time, also diminishes quickly.
I would suggest that maintainers take the time to go through contributors and give maintenance rights to folks who have made significant enough contributions to possibly get out of the current situation. Just my two cents.
Time passes and I again want to appeal to people with PR merger rights (can we have the list of these people anywhere?). Unfortunately, the number of requests and PR is growing, but most of them do not receive any attention from maintainers. I see a bad signs in that approach. If maintainers don't have enough time for a project, shouldn't they to request help from community by giving them PR merging rights? @dtolnay, @oli-obk , what do you think?
I think the right approach is to finish the serde_core work and let the community handle forking and modularizing serde_derive.
No one is actually blocked on that tho, as you can use serde without serde_derive already. In my book serde_derive is in maintenance mode and will only receive critical bug fixes or rare features at maintainer discretion. Not sure if that is also David's view, but it is how I approach this
Not all problems related to serde_derive and not all of them can be solved without changing core serde traits. This is especially applicable to various model transformation derives, such as flattening. What the plans to proceed with them? Examples are Deserialzier::__deserialize_content and Visitor::__private_visit_untagged_option.
IMO serde_derive being in "maintenance mode" is not the same as it being "unmaintained." I don't think it should warrant a RustSec advisory.
I think the right approach is to finish the
serde_corework and let the community handle forking and modularizingserde_derive.
I am curious if this still feels like the path forward. It looks like the serde_core work has been making progress again recently; does it still look like the community forking serde_derive is the right solution?
IMO
serde_derivebeing in "maintenance mode" is not the same as it being "unmaintained."
I do not see any maintenance related to specifically serde_derive. That just words which does not correspond with actions. The actual status is "unmaintained". The issues/PRs does not get any attention. I does not mean that they should be merged immediately after creation. But I at least expect that someone with merge rights somehow comment the work.
As I understand it, "maintenance mode" usually means maintainers are not merging any new features, but will address critical bugs and security vulnerabilities that are raised. Are there any issues like that which are not being addressed?
What is critical bug in derive crate? When the hard drive are formating during compiling? Something less destructive, like #2520, is not enough? As I understand "maintenance mode", the authors does not write any code, except "critical bugs and security vulnerabilities", but review incoming PRs and releases new version with fixes, made by other people.
As I understand "maintenance mode", the authors does not write any code, except "critical bugs and security vulnerabilities", but review incoming PRs and releases new version with fixes, made by other people.
Opinions on that differ. Considering I am subscribed to all of serde and see every message, I would consider it maintained.
Merging code in a project that works well is not necessary for it being maintained.
Also as stated many times: the way to speed up serde reviews and merges is to make crater-at-home support branches of a crate being tested against all of crates.io
Considering you are very well aware of this, I am not sure why you are trying the nuclear route of having half of crates.io get security advisories
Also as stated many times: the way to speed up serde reviews and merges is to make crater-at-home support branches of a crate being tested against all of crates.io
Okay, where is this work going? Is there something more weighty than wishes? What is being done to achieve this? Why it is needed for obvious bug fixes? Are you worried about those who have errors in serde break their erroneous code, but not those who have these errors that prevent them from writing correct code? It's surreal.
Is it not better to invest in improving the test coverage in order to be sure that nothing breaks down, and if it changes, then in a limited and predictable way? By the way, some of my PRs just concern only tests, do they really depend on the ability to check all crates with the new serde? Or minor refactorings?
Considering you are very well aware of this, I am not sure why you are trying the nuclear route of having half of crates.io get security advisories
Firstly, the message is informational (perhaps it is not taken into account or filtered by tools), secondly, not everyone has a warning (probably even a minority), and thirdly, those who have them configured, I think, are interested in solving problems in their dependencies, and not hanging for years in an indefinite status.
For 5 years since the creation of this issue, absolutely no progress is visible, and if you do not remind about it, then they will generally prefer to forget about it. No offence.
I try to work on many future PRs for serde and I again and again come across problems that I have already solved in PRs that have not even been considered. I can't call this situation normal. It just complicates my job, as I try to make my contributions independent of each other, hoping that this will increase their chance of merging (ha-ha). Improvements are usually made in small steps, based on each other. Big PR is hard to manage, hard to review (psychologically, even if every commit is self-evident, which I try to stick to).
Are you worried about those who have errors in serde break their erroneous code, but not those who have these errors that prevent them from writing correct code? It's surreal.
Is it not better to invest in improving the test coverage in order to be sure that nothing breaks down, and if it changes, then in a limited and predictable way?
I mostly work on the Rust compiler itself. We have 20k tests. We regularly make changes where we make changes that are breaking in really weird ways so we test crater to see if at least the linux using portion of crates.io does not use this. We also run crater on every release (well on the beta before the release), to know ahead of time if we accidentally broke something. Frequently this turns up cases we did not have tests for, and thus added those new tests.
A crate that can break half of crates.io should imo be held to similar standards. Opinions on this differ, but this is my personal opinion.
By the way, some of my PRs just concern only tests, do they really depend on the ability to check all crates with the new serde? Or minor refactorings?
You have opened so many PRs, that unless it's something I can immediately see the use of or have the context available, I ignore it until I reviewed the oldest ones. Even then I mostly ignore PRs until important ones have landed. Yes the serde-core reviews took forever, but now that it's ready I'm not landing anything new until we get that over the finish line.
Minor refactorings frequently cause fallout in the rust project.
Yea we could land the test PRs, but iirc there were some open that depended on changes to serde-test which has since been deprecated so I have no idea what to do with all of that and getting it into my own cache is a lot of effort that I don't really see how worth it it is.
Okay, where is this work going? Is there something more weighty than wishes? What is being done to achieve this? Why it is needed for obvious bug fixes?
It is going nowhere. It is my wish that this is done before we land some more complex things. Nothing is being done to achieve this. Obvious bug fixes may break spacebar-heating situations of some people, and if such a crate is used widely, its impact may be significant. We need to coordinate with such users.
I am not working on this and have no interest in actually being in charge of this work. I just stated how to give us confidence into merging sth that we have a lot of trouble judging unintended effects of.
Are you worried about those who have errors in serde break their erroneous code, but not those who have these errors that prevent them from writing correct code? It's surreal.
I am not sure if you are using "error" for "wrong behaviour" here, but if you are, then yes and no. I am worried about both cases. The latter can at least write manual expansions and/or their own derives. The former would just get their "perfectly working" (to them) code broken in possibly only-seen-in-production-code ways.
Yea we could land the test PRs, but iirc there were some open that depended on changes to serde-test which has since been deprecated so I have no idea what to do with all of that and getting it into my own cache is a lot of effort that I don't really see how worth it it is.
Only one (#2781) and I wrote in the very first message, that it is possible to drop commit that depends on the unmerged serde_test PR. If this is not a clear description, then I have no idea how to make it clearer.
I can immediately see the use of or have the context available
That is why I always split my work on small commits ant try to not exceed threshold for 10-15 commits in my PRs. I also recommends to review each commit separately.
You have opened so many PRs
Naturally, if they are not reviewed and merged, their number only grows. I have only 15 opened PRs for 5 years. Not so much, ~1 PR/month (if include closed PRs -- 15+46=61 for 5 years=60 months).
It is going nowhere. It is my wish that this is done before we land some more complex things. Nothing is being done to achieve this.
What do you think is required to make this possible? Is the Rust Foundation aware with those problems, may they help?
Obvious bug fixes may break spacebar-heating situations of some people, and if such a crate is used widely, its impact may be significant. We need to coordinate with such users.
The solution is semver, but serde does not follow it... But anyway, downstream projects can lock their serde version, this is a trivial change. If they rely on erroneouses behaviour that is only their problems and I do not see any good points to encourage such practices.
The former would just get their "perfectly working" (to them) code broken in possibly only-seen-in-production-code ways.
That argument is not valid for PRs that turns runtime errors into compile-time errors (#2937). It also almost invalid for serde_derive changes, because possible combinations are small and the full set can be tested. There is simply no need to test on third-party projects if you can write comprehensive tests. In my PRs that change such behavior, I wrote just such (#1922, #2445, #2520, #2561, #2781, #2811)