Find another maintainer

[ndmitchell]

I don't use the project myself, with the several programmable type-class features in GHC it's less important, and the projects which would have a serious need for this kind of thing (e.g. lens) contain the code themselves. To remain relevant and useful some thought should probably be given to exactly what derive should do, and how it should do it, and given I have no itch to scratch, I'm the wrong person to do it.

On the flip side, there are 67 reverse dependencies, so it's a fairly well-used project. I'll keep up with bug fixes for the time being, but aim to find an alternative maintainer (or co-maintainer to start with). This ticket is to write a blog post for that.

[FranklinChen]

I just used derive to generate QuickCheck Arbitrary, first time I've ever used derive.

By the way, the Hackage page https://hackage.haskell.org/package/derive points to http://community.haskell.org/~ndm/derive/ where there is nonexistent link to a manual https://rawgithub.com/ndmitchell/derive/master/derive.htm, so I see the need for a maintainer :-). I'm still completely new to derivations, however, and am planning to learn how to write my own.

[ndmitchell]

I've uploaded derive-2.5.21 with the fixed home page - there are many reasons it needs a new maintainer, but dodgy web links shouldn't be one!

[ndmitchell]

Blog post published: https://neilmitchell.blogspot.co.uk/2016/07/maintainer-required-for-derive.html

[tomberek]

I am interested in maintaining a library. I've done a little work with template Haskell and derive.

Before I do anything like this I'd like to have a conversation about where you see the library going, remaining issues and problems, and to make sure I'd be a good fit.

pa-ba/compdata#14

[ndmitchell]

The main work required is to follow both template-haskell and haskell-src-exts releases and keep on top of them.

On a day to day maintenance, there are a few things. There is lots of scope for improving code quality - lots of modules lack explicit export lists for example. There are CPP definitions for GHC 6.12, which could be removed. The library is more useful the more types of derivation it supports, and there are plenty of new ones it doesn't support at all. The test suite is in a reasonable shape though.

On the forward looking, there is the question of how this related to GHC's generic deriving. Maybe this is a more convenient way to specify such an instance? Maybe there is some other relationship? Maybe it's all about generating instances that auto-specialise and chase the high-performance end? I'd like the library to be useful to the people who have already started using it, but as I don't use it, I don't consider myself to have much opinion on where it goes from here.

[ndmitchell]

The need has arisen to make a fairly substantial haskell-src-exts upgrade, as tracked in #19.

I've done a bunch of work on it, but absent another maintainer, I don't really intend to keep doing that. If another maintainer isn't found I'll probably just keep the tight bound on an old haskell-src-exts and remove derive from Stackage.

[ndmitchell]

I've removed derive from Stackage: commercialhaskell/stackage#1772

[mgajda]

Can do lah!
Shall we make GitHub organization for maintaining Derive?

[ndmitchell]

That's up to you and @tomberek or anyone else who offers. I'd just fork the project or have me transfer ownership unless two of you want to co-maintain, and in that case you can make an organisation or anything else you fancy.

[ndmitchell]

So I'd like to get this issue closed out, and give over maintainership, as there are questions trickling in that I don't feel anyone is in a place to reply to without a proper maintainer. @tomberek @mgajda - are you happy to be co-maintainers? Or does one want to take it with the other a sub-maintainer? Do you want to set up an organisation, or just one of you clone it and give the other write permission (that works just fine if it's only two of you). I suggest your first order of business should be a new 0.0.1 release changing the maintainer field - and then this bug will be well and truly closed.