Maintainership of failure

[withoutboats]

Its obvious that I have too many things on my plate, and long term maintainership of failure is going to be one that gets dropped off. I'd like to try to push it over to a 1.0 release and then largely pass on authority over this crate to a team of interested individuals. In the long run I am also in favor of pulling parts of the API here into std, probably starting with a standardized backtrace API.

If anyone is interested in being involved in maintaining failure, please post your thoughts here. :)

cc people who have expressed interest in maintaining failure in the past: @aturon @mitsuhiko @kamalmarhubi

[mitsuhiko]

I'm very interested in this. Feel free to drop me a mail and we can have a chat.

[kamalmarhubi]

I'm also quite interested in doing what I can to get this to 1.0 and beyond.

[otavio]

I am too new to Rust to take a maintainership role but I am willing to help to test and even reviewing stuff.

[aturon]

Great to see this picking back up! I don't have bandwidth to be very actively involved, but I would like to try to do a "brain dump" of the notes I had taken when I was more involved, to pass along to y'all. I'll try to do that soon.

[withoutboats]

Thanks for writing in everyone! 🎉 I think we should start by trying to get a stable release out & setting a roadmap for feature priority beyond 1.0.

I've started labeling issues that need a decision before 1.0 (because it would be a breaking change to change them). The other big thing that needs to be done is to review the code to make sure its all correct - for example, I was told the throw! macro is subtly different from the behavior of ?, so that needs to be fixed.

[withoutboats]

Oh I also want to do a "crater run" for 1.0.

The way the 1.0 release is planned, the 0.1 version should be "compatible" with the 1.0 version, in that none of the breaking changes change the public API someone could re-export from failure. They change code generation, but not the API of Error and Fail. This uses the dtolnay semver trick.

The way this works, the next 0.1.X release will have a dependency on the 1.0.0 release. I want to actually build all the crates on crates.io against the new 0.1.X version to confirm it is indeed not a breaking change for anyone.

[BurntSushi]

I'm interested as well. I am also stretched quite thin myself, but I care a lot about error handling and so I would like to help out where I can.

[kamalmarhubi]

@aturon that brain dump, however raw, would be super useful!

@withoutboats are there any areas you'd want new / prospective maintainers to start looking at in the very near term?

Also when thinking about the API, I hope we can get your input on things occasionally. You're both really thoughtful API designers, and ideally failure keeps being thoughtful even if you're less directly involved. :-)

[aturon]

@kamalmarhubi Oh, I'm very happy to be consulted as things come up, just can't lead the charge.

So, I have a few sets of notes. First, there are two very rough notes written by other folks who were struggling with the crate:

• Challenges learning failure
• failure issues
  • Note that this one, in particular, contains incorrect information based on misunderstanding; I have some comments on the side where this happens. But that's useful feedback in and of itself!

Then, there's a set of notes I wrote trying to lay out my own view on how the crate should be used and what direction it should go in:

• How to failure

A central aspect in all of this is that the core mechanisms are pretty simple/uncontroversial, and most of the issues are around docs/advice/patterns.

Please feel free to ask any clarifying questions here. This stuff is very out of cache for me right now, but if you poke me I should be able to dig the thinking back out.

[mitsuhiko]

I'm still very interested in maintaining this project but I would like to vote on not releasing failure without a lot of further consideration. There are a few API warts that I think are very resolvable but were not properly discussed yet. If there is interest I would like to write down some notes on problems we ran into and some proposals we have for solving them.

[aturon]

@mitsuhiko Agreed!

Personally, I would love to see some equivalent of an RFC if/when maintainers feel they have a 1.0-ready design, to build community consensus and pave the way toward eventual inclusion in std.

[withoutboats]

@mitsuhiko I completely agree that the APIs need careful review before any 1.0 is released. Things like the unnecessary where Self: Sized bound you caught today are good examples.

Where @aturon and I have had some disagreement in the past is that I think a significant or fundamental revision would be better done as a new crate than having failure 1.0 be different in a really big way from failure 0.1. I also strongly value having types between 1.0 and 0.1 be interchangeable.

[BurntSushi]

Where @aturon and I have had some disagreement in the past is that I think a significant or fundamental revision would be better done as a new crate than having failure 1.0 be different in a really big way from failure 0.1. I also strongly value having types between 1.0 and 0.1 be interchangeable.

Interesting. I didn't consider this, but I definitely have grown some very loose opinions about doing things somewhat differently than what failure is doing. But since I haven't experimented with it at all, I don't know how well those opinions would work out. Mostly the thing stopping me from pushing forward is the desire to coalesce on one answer (failure), and, of course, time. But maybe I'll try to slap something together.

[aturon]

A related issue to this discussion: whether there are perhaps some separable pieces at play here. I think we all agree that the Error trait in std is broken (e.g., because it failed to impose the 'static bound needed to support downcasting); if we can at least get agreement on a replacement core trait, that'd be a big step forward.