Maintenance Status

[ten3roberts]

Hello @yaahc . What is the current status of this library?

I've found it to be fantastic to use (especially with color-eyre) for constructing rich errors as well as getting a readable panic hook.

However, I've had to go back to anyhow and stop using this library in flax and other libraries due to the Miri/memory invalidations as well as other missing features.

It would be great to have this crate up to speed.

If you do not have the time, which is completely understandable as an open-source maintainer myself, is there any other crate which achieves a similar goal of rich errors and panic messages that you would recommend?

Best regards, Tei

[yaahc]

I've been struggling with maintenance on this crate. I still want to keep it up to date and am interested in growing the team to enable others to come in and help maintain it, but I haven't invested enough time into it to make any progress.

Part of the reason I've been having difficulty is that I got really burnt out being in the library team review rotation for a year and a half, and my brain just shuts down whenever I try to do similar work these days. I'm working on recovering from that burnout, but governance work has consistently delayed my efforts to invest more in technical work.

For now, I know that https://docs.rs/error-stack and https://docs.rs/miette both take very similar approaches (miette started as a fork of eyre, not sure how much it has diverged over time but I'm guessing not a ton). I don't want to say that this crate is unmaintained but honestly it might as well be until I get my shit together.

[ten3roberts]

Oh that does not sound good, make sure to rest up properly and grow stronger than before.

What sold me on eyre was the hook and panic integration, as well as the seamless integration with tracing and backtraces.

I've been absolutely loving my panic messages and errors with color-eyre as they are readable, and my code is colored differently from other code so that I can find the cause instantly. I've found the std panics to be extremely hard to read.

I've used it in my ECS library flax for reporting system execution failures from a scheduler. The produced error messages were absolutely fantastic, rich and easy to diagnose the cause and chain of events for.

Another aspect that I like is that it is simple and predictable, as it uses the standard error trait and is consistent with the existing std library error architecture, whereas miette (a strong contender) uses a custom diagnostics trait which does not necessarily fit your use case, as it is very specific to parsing and source code derived errors and seldom fits other code with the source and url parts of the trait sticking out like unused but possibly present sore thumbs.

I would love for eyre to get some more love and find maintainers. Is there anything I can do to help in that regard?

[yaahc]

I would love for eyre to get some more love and find maintainers. Is there anything I can do to help in that regard?

Yes, absolutely! If you'd be interested in helping with code review and maintenance, I think that would help me a great deal, and I'd still be able to chip in. I'm hoping just having some more company and splitting the load would go a long way toward making maintenance here sustainable for me¹.

Would you be interested in jumping on a call sometime to talk about the maintenance story for this crate, our collective capacity, and do some planning?

Footnotes

1. I'm also using eyre again in a work project recently so I'm getting more use out of it for the first time in a while now which I'm hoping will also help me build motivation for maint work. ↩

[ten3roberts]

That is good to hear. I'd definitely be up to helping out with code review and other maintenance, though I may not have the greatest ability to write code due to my current stance of other projects, but that can and will shift in the future when I finish up PRs.

Jumping on a call sounds great. My timezone is currently CET (Z+2H) and I am mostly available for calls during evenings or weekends.

I consider this issue to also be applicable to color-eyre as it is what I use mos frequently alongside eyre, and would as such like to contribute and bring both crates up to speed.

[pksunkara]

I would also be willing to lend a helping hand.

[yaahc]

@ten3roberts and @pksunkara, sorry again for the long delays and thank you again so much for the support and understanding. I wanted to spend some time thinking about building a community around eyre and friends and get some advice from @alice-i-cecile, but we had trouble finding time to chat. We ultimately ended up having our chat yesterday, which was very helpful.

The core of the advice was mainly about how to empower people asynchronously, onboard incrementally, and how to model various roles and responsibilities in the project. Here's my immediate plan atm:

• write up some short docs on contribution within eyre (and by extension, color-eyre and all the projects I currently maintain/own).
  • I think the most relevant bit is going to be defining how we do code reviews, I want to encourage people and make it clear that anyone can submit code reviews to open PRs, which I can then triage and merge by controversy or lack thereof
  • over time I anticipate sharing write permissions with more active contributors so they can start also handling merging PRs
  • long term goal is to grow the set of people with publish permissions on the crates and increase the project's bus factor
  • As part of the contribution docs I'm gonna try to outline the various roles / responsibilities and the expectations for each one (e.g. for write perms, merging PRs, and especially publishing crates, a solid understanding of semver and stability hazards is probably an important requirement. Not sure exactly what it will all look like in the end but I expect it to evolve over time so I'm not gonna worry about the initial mental model too much.)
• I'd like to immediately give both of you triage permissions on eyre/color-eyre (@pksunkara not sure if you're only interested in eyre, lmk)

I still want to setup a call to chat to get to know y'all, exchange feedback and ideas, that kinda thing, but hopefully we can decouple that from y'all being able to get started. Once again, I extremely appreciate the help y'all, seriously makes me so happy to finally be building up towards these crates being owned by more than just me ^__^.

Here's a lettucemeet with my availability for the next week where y'all can enter your availability and contact info so I can schedule some introductory chats https://lettucemeet.com/l/KBOvL

[yaahc]

I think I might have to move this repo into an organization in order to setup the permissions the way I want... apologies if you get a bunch of random emails while I'm figuring this out 😅

edit: okay I think I got it all figured out

[pksunkara]

I am interested in the eyre ecosystem completely since I think it's the best way to handle errors right now.

So, I wouldn't mind if you add me a collaborator to the entire organization instead of just this repo.

[yaahc]

I am interested in the eyre ecosystem completely since I think it's the best way to handle errors right now.

Hell yeah

So, I wouldn't mind if you add me a collaborator to the entire organization instead of just this repo.

+1. I don't think I can control permissions for org members the same way I can for repo members, but I went ahead and added you to all the repos.

Also, this begs the question of which repos should I be transferring into eyre-rs? I started with eyre, color-eyre, and indenter, but there's also stuff like simple-eyre and stable-eyre which I don't think anyone really uses, not sure. There's also displaydoc which is quite popular but only vaguely related to the rest of the eyre crates. I'd love to build a community around that crate as well but I'm not sure if it makes sense to combine it with the eyre organization.

Curious what y'all think. Also @pksunkara you replied so fast I'm not sure if you had a chance to see the edits I made to the original post, so I wanted to point out that I added a lettucemeet for scheduling incase you wanna sync up sometime next week.

[pksunkara]

If something is not being used, we can always archive them later but I would recommend moving the following:

• simple-eyre
• stable-eyre
• color-spantrace

There's also https://github.com/athre0z/color-backtrace but I realize that you don't own it.

I am ambivalent about displaydoc but I will leave the decision up to you.

[yaahc]

I went ahead and moved the three you suggested(good catch on color-spantrace) and left displaydoc for now, I figure we can always move that later, similar logic to the archiving for unused crates.

Ty both for adding your availability. Before I schedule the actual call I wanna make sure to check in with everyone on our preferences for how many calls to setup. I see two options, either one call with all three of us or two 1x1 calls.

My preference is probably the group call, my reasoning being that if our shared goal here is to build a community it's probably more helpful to communicate as a group rather than a collection of individuals. That said I have no objections to meeting 1 on 1. Let me know what y'all prefer, if you have alternative proposals, or objections to any specific proposal.

[pksunkara]

I would prefer a group call too.

[ten3roberts]

A group call would be preferred. It seems as if Tuesday has the longest available time in case time runs late.

I believe @pksunkara is in a similar timezone, so that time is evening and night for us.

Monday also works, as we should hopefully not need that much time 😄

I am flexible and can shift things around a little in case needed

Looking forward to getting started on this. I have some questions and considerations regarding larger pieces of work, and how we should think architecturally going forwards.

[yaahc]

Hey @pksunkara, I just wanted to update you on the first meeting because we missed you. Unsure if there was a breakdown with the notifications from lettucemeet or if you had something come up. Either way, I should have confirmed the time in the thread, so that's my bad.

Anyways, @ten3roberts and I met up a couple of hours ago and chatted about which issues we need to fix most urgently and some other improvements we can make to the projects to improve overall maintainability. The main suggestion is to combine the main crates into a mono repo so people don't have to worry about which repo they should open an issue on and having issues being opened on the wrong repos. We also discussed fixing the MIRI issues and some ways to more easily pull in updates from anyhow.

Our plan is to meet weekly, at least until we can get through the backlog and get the crates into a good state. These meetings would focus on triaging open issues and PRs, working together to resolve them, and coordinating or co-working as necessary. We expected to switch to a slower cadence of check-ins and more async work over time as we get to know each other and how we all like to work.

Let me know if the time we selected (20:00 UTC Tuesdays) works well for you. I look forward to being able to catch up with you in a future meeting ^_^

[pksunkara]

Thanks for the update.

Unsure if there was a breakdown with the notifications from lettucemeet or if you had something come up.

Sorry, It was a mistake on my side. The phone notification system I generally rely upon to attend a meeting didn't work and I was completely immersed in something else.

Let me know if the time we selected (20:00 UTC Tuesdays) works well for you.

Yes, it does. Are we meeting again next week?

[yaahc]

Yes, it does. Are we meeting again next week?

yup!