Package errors looking for new maintainers

[davecheney]

Package errors looking for new maintainers

[jackwhelpton]

I no longer use this package, in fact I no longer wrap errors. This sounds like a grandiose claim, and it may be my quirky coding style (my other views on error handling are hardly commonplace), so I don’t mean this comment to be a judgement on anyone who uses this package and enjoys it. It’s simply that it’s hard to make time to work on something which I no longer believe in.

@davecheney: I'd be very interested in reading a blog post on this if life ever permits again; although you may find your error handling ideas quirky, your previous writings on the subject have been required reading for our team.

[mfridman]

Curious, this package is under the pkg organization with a few well-respected folks from the Go community (at least those that are public), could them collectively lightly maintain pkg/errors in its current form? Having used this package from the very beginning one could argue its feature complete and doesn't need much maintenance.

For what it's worth I still use this package, and will continue to do so until the standard library is at least feature parity with pkg/errors. This was the premise of xerrors, but in my opinion it removed too many useful features, namely stack traces on errors.

Edit: a big thank you for open sourcing, maintaining and resolving issues and bugs! Open source works best when we collaborate.

[davecheney]

@mfridman you are correct that this package pretty much does what it says on the tin, and at this point can’t really do something different without the trauma of introducing errors/v2.

Perhaps the better solution is to archive this project and let development continue in forks.

[mfridman]

Pretty much any way its sliced will be a breaking change. The ideal scenario would have been for the Go team to provide a smooth transition to the standard library while offering the most common feature set among error packages, but that's not here nor there.

My vote goes towards sunsetting (archiving) this package with a short blurb on what this package is and maybe a small blurb on the history of how we got here.

If a fork spawns, and gains popularity .. it is what it is. But I'd rather see this package live another day in its current form, as opposed to new maintainers who (quite often) get feature happy.