Package errors looking for new maintainers

[davecheney]

Hello,

Quite clearly this package has been unmaintained for a long time. There are two main reasons for this (along with several others — waves in the general direction of life)

1. I had hoped that with the integration of some of the ideas from this package into Go 1.8 (I think) then the use of and need for this package would decrease. Sadly for whatever reason Go errors did not obtain the feature that this package was built for — stack traces on errors, so the need for this package remained.
2. 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.

Having got this off my chest, I recognise that this package holds a useful place in the Go ecosystem so it deserves more attention than it’s got over the last few years.

To that end, I welcome expressions of interest in the comments below.

Thank you

[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.

[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.