Is Flycheck a dead project?

I was looking at using Flycheck today with lsp-mode, and I got a warning from lsp-mode. A quick google lead me to a github issue for lsp-mode that said it's a common problem and that Flycheck was going to release a new version that fixed it. There was linked issue from that one to a github issue on Flycheck's repo about releasing said version from 2020, with no actual traction on finishing the release. There haven't been any commits to `master` since August 2021, regardless of the fact that there are 45 open pull requests, and users requesting that a new release be cut for 2 years. Their CI jobs don't run anymore because they're linked to travis-ci.org which has been in read-only mode since July 2021 and no longer accepts new build jobs. Is Flycheck dead? Are people just using snapshots from the repo to make it work? Is there a forked version someone is actually mantaining?

Good question. lsp mode should also wirk with the build-in flymake.

It does, but from what I understand FlyCheck is faster and supports more features/languages out of the box, hence my attempting to move over to it. FlyMake works for now.

Generally, it is fine to use melpa version of flycheck.

I think we generally have a problem with widely used packages that are unmaintained. Maybe it would be a good idea to add a list of packages somewhere that don't have maintainers anymore so people can take ownership. I've already thought about posting this on reddit but I wasn't sure if the community liked the idea.

with a good language seever the speed of flymake shouldn't be a problem, and AFAIR flymake worked faster than flycheck when I've tried it with lsp-mode. Flymake got better recently, you may want to install newer version from ELPA

Someone asked if they could shepherd the release for them about a year ago, and was met with silence. The person had already done all of the work, they just needed access to push the release to the repo. I think it's simply that the maintainers have walked away without promoting anyone else to have access.

I think flymake was rewritten recently and works very well with eglot

Maybe you're right. However I also experienced that former maintainers are hesitant to add new maintainers when they aren't sure that somebody has enough experience and/or ensures that a package doesn't break every second commit. I think this is understandable especially when a package already works fine for most people. But it's also sad when great packages like flycheck stay unmaintained for years...

There is the [emacs orphanage](https://github.com/orgs/emacsorphanage/repositories).

Note that the standard (built-in) Flymake was significantly rewritten since Flycheck was created, so it's probably sensible to use Flymake if that supports your use-case. https://git.savannah.gnu.org/cgit/emacs.git/tree/etc/NEWS.26?h=master#n1163 See `C-h i g (flymake)` for more. If you wish, you can also install the latest version from GNU ELPA with `package-install`, as the ELPA package tracks releases made during core Emacs development. https://elpa.gnu.org/packages/flymake.html (But note that most of the extension packages implementing specific flymake backends seem to be in MELPA.)

That's a worrying amount of packages.

But there hasn't been a commit to `master` of flycheck since August 2021. That's also worrying.

This is always one of the things I worry about when I think about emacs. IMO, it lives or dies based off the strength of its third-party packages, and if people aren't working on packages...

Sounds like maybe what would be worthwhile would be to fork the package and release it under a modified name. While it wouldn't be immediate, just communicating the existence of a new package to things like Doom or Spacemacs would already help with moving things forward (and libs like \`lsp-mode\` could add warnings or do things on its end as well)

I don’t think flycheck is on ELPA? https://github.com/flycheck/flycheck/issues/801 Do you mean flymake in your last paragraph?

Plus if you want a comprehensive collection of checkers like flycheck you should checkout flymake-rest. Looks like the authors just been porting checkers from flycheck LMAO. Still great work :-).

I've no idea whether anyone is maintaining flycheck or not, but... > there hasn't been a commit to master of flycheck since August 2021. That's also worrying. That's only six months. Why on earth would you be panicking over such a short duration?

Yes, sorry for confusion! I've edited the comment

I know emacs orphanage but there are plenty of packages that are not in it because nobody moved it there.

> There haven't been any commits to master since August 2021, regardless of the fact that there are 45 open pull requests I understand the worries, but it is not a measure of the project being dead or not. Just because there is no release for a year, does not mean it is dead. If the project is stable and has all the features devs wanted from it, then it is to expect that development is stale and slow. Is there some broken thing that needs to be fixed? Also, since built-in alternative has gotten better, maybe it is wise for devs to wait and see how the future will look like. There is no need to waste their time, if everyone will switch to LSP or Flymake and what not.

I wonder if we just have the problem that there aren't enough users in the community that are interested in maintaining a package or if there are potential maintainers but we don't get them "on board". I guess that would be a similar issue with emacs itself. There would be at least twice the number of contributors and commits if the project would be maintained in gitlab. I don't want to blame anybody but I think we all know that it's the truth.

Yes, I imagine it's tricky when a maintainer doesn't actively drop a package off at the orphanage, nor mark their package unmaintained, but instead just stops responding. It's a gray area. What's a reasonable response time? 1 week? 1 month? 1 year? The answer might differ depending on the package. Perhaps we need an **Emacs Package Protective Services**, drawn from Emacs/ELPA/MELPA leadership. They can serve as a collection point for "package concerns", and notify a package maintainer (via an email or an issue) that their package has been deemed high-value, and reported as unmaintained by numerous users over a period of time. Then they can layout the next steps, which could include: 1. Stimulating the maintainer to mark their package unmaintained (which might be a fine endpoint for many lesser used packages), or transfer it to the orphanage. 2. Matching skilled and vetted volunteer users as EPPS *co-maintainers* for the package (in its original repo). 3. Matching such volunteers as new maintainers, for transfership. 4. (*last resort, license-permitting*) Forking the package to the orphanage and making it the ELPA/MELPA canonical upstream (with the maintenance help of volunteer maintainers). It would require a great deal of care and fine judgement. You don't want to run off the very volunteers that make this community work. And, even with all this care taken, there is *still* gray area: does an unmaintained package that works just fine for many users count? What about the "first do no harm" principle? Camping on a serviceable but unmaintained packaged at least keeps it operational. And here's the important point to note: *volunteer effort is required for each and every one of these options*. Such a setup seems like it would at least have worked for flycheck. Go adopt a package!

[deleted]

One final perspective: writing a package to solve a burning problem is fun. Maintaining a package is (usually) less fun. The problem has been \~solved. The fire has been put out. The itch has been scratched. Now you are just walking around the perimeter dousing small hotspots. Important work? Yes. Exciting? No. There's a reason there are so many packages that are 4-6 years old, which have equally old language in their README such as "*In the next release, we will improve features X & Y, and add feature Z*". The next release never came. There is a natural cycle of life that should be respected. Many packages *should* be allowed to die with dignity, their ideas and techniques recycled back into the great collective, the raw material for a new generation, fueling new solutions to new problems, new fires to quench.

Not only with eglot. It also works with lsp-mode like a charm.

Also shows some value of moving popular packages into emacs/ elpa

I said "worrying", not panicking.

But that makes it *harder* for people to contribute.

Why on earth would you be worrying over such a short duration?

OP mentioned a bug that's fixed in a new release... which was supposed to come out in 2020. Presumably there are other bugs not being fixed because the maintainer isn't merging PRs.

Reduces the risk of it becoming abandoned a lot

It's a double.edged sword. Less likely to be totally abandoned, but also has a higher barrier to contributions because it's harder to contribute to emacs core than it is to send a PR on github/gitlab/whatever.

It’s not that hard though… takes a little bit more effort in the beginning

Disclosure: I'm one of the two co-maintainers. The answer to the top question is no, I think. We still have maintainers (including me) looking at the PRs. But I've had very little free time to spend on Flycheck, and we haven't had anyone step up to a co-maintainer. We'd love to onboard more people. And we'd love help. If you can review PRs, test them locally, and comment, that helps a lot. I have felt little need to make a release because the vast majority of users use MELPA, not MELPA stable.

Do you have a link?

FWIW, we'd love to onboard new maintainers. So I don't think a fork would be necessary (?)

That's fair, but the current maintainer team (as inactive as it is) did not write the original software. Besides, there is still \*a lot\* to do in Flycheck.

The main difficulty is finding time to review the PRs. If you can, please do. I've been one of the maintainers for a while, but it's hard to find time to review PRs that fix issues with flycheck checkers that I've never used for languages that I don't use either :/ That's a lot of the PRs these days.

Unmaintained for years is a bit harsh, I think \^\^

I just wanted to emphasize the value of flycheck for the emacs ecosystem. I know it's not completely unmaintained, sorry for that ;) And I don't want to blame anybody for not having more time, we all have other responsibilities. But it's an issue and it seems to be getting worse. When I compare it to the time when I started emacs 5 years ago, many old maintainers retired more or less. And I don't see that new people are taking their place. But maybe I'm wrong.

Sorry, I was speaking under the assumption that there wasn't really that as an option (since that happens from time to time with this kind of thing), being able to onboard new maintainers and having things move forward that way is definitely better!

https://github.com/flycheck/flycheck/issues/1754#issuecomment-867566141

Thanks, done now.