ndmitchell / derive

A Haskell program and library to derive instances for data types
BSD 3-Clause "New" or "Revised" License
25 stars 17 forks source link

Find another maintainer #6

Open ndmitchell opened 9 years ago

ndmitchell commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 8 years ago

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

tomberek commented 8 years ago

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.

https://github.com/pa-ba/compdata/pull/14

ndmitchell commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

I've removed derive from Stackage: https://github.com/fpco/stackage/pull/1772

mgajda commented 8 years ago

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

ndmitchell commented 8 years ago

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 commented 7 years ago

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.

ddssff commented 7 years ago

I would join a github derive maintainer group.

ndmitchell commented 7 years ago

@ddssff everyone who has said they would be happy to be a maintainer hasn't yet actually created a maintainer group. If you do that, it's all yours!

ndmitchell commented 7 years ago

@ddssff thanks for creating https://github.com/DeriveMaintainers. I note that the project th-typegraph is already assigned to that project - was it intentional?

ddssff commented 7 years ago

Yes, its my solution to #13. It could use some polish though.

ndmitchell commented 7 years ago

Cool, as long as it's intentional that seems sensible.