On 2008.06.20 17:06:28 +0100, Adrian Hey
Hello Jean-Philippe
Jean-Philippe Bernardy wrote:
* I have no time to maintain collections. As Adrian said before, this is an unpaid, thankless job.
I suspect Gwern Branwen feels the same way after all this :-)
I'm used to it. And this sort of thing is easier than a lot of Haskell-related stuff (I would freeze in stark terror if asked to try to write something like Edward's category library), after all. And I got used to being yelled at on Wikipedia and Usenet. :)
Maybe it would be a good idea to do a 0.4 release for the benefit of anyone interested (0.3 did have some users I believe), especially as the 0.3 release seems to have disappeared (not sure why that is).
But it would be good to get the dependencies right and make sure we don't have multiple sources for "the same" code.
AFAIK enumset isn't in hackage at all at the moment and it may well be useful to someone, but is what's in the collections repository the latest official version or is it being worked on elsewhere?
I agree. But what do we need to do for a cleaned up release? * I think we obviously need to remove you from the various maintainer fields. You seem to be in ~half of them: gwern@craft:11210~/bin/collections-ghc6.8>grep maintainer: `find . -name "*.cabal"|grep -v _darcs` [ 2:06AM] ./collections.cabal:maintainer: jeanphilippe.bernardy (google mail) ./Data-Tree-AVL/dist/Data-Tree-AVL-0.4/Data-Tree-AVL.cabal:maintainer: http://homepages.nildram.co.uk/~ahey/em.png ./Data-Tree-AVL/Data-Tree-AVL.cabal:maintainer: http://homepages.nildram.co.uk/~ahey/em.png ./Data-COrdering/dist/Data-COrdering-0.4/Data-COrdering.cabal:maintainer: http://homepages.nildram.co.uk/~ahey/em.png ./Data-COrdering/Data-COrdering.cabal:maintainer: http://homepages.nildram.co.uk/~ahey/em.png ./Data-Trie-General-OrdGT/dist/Data-Trie-General-OrdGT-0.4/Data-Trie-General-OrdGT.cabal:maintainer: http://homepages.nildram.co.uk/~ahey/em.png ./Data-Trie-General-OrdGT/Data-Trie-General-OrdGT.cabal:maintainer: http://homepages.nildram.co.uk/~ahey/em.png ./collections-base-instances/collections-base-instances.cabal:maintainer: jeanphilippe.bernardy (google mail) ./collections-base-instances/dist/collections-base-instances-0.4/collections-base-instances.cabal:maintainer: jeanphilippe.bernardy (google mail) ./collections-rangedsets-instances/collections-rangedsets-instances.cabal:maintainer: jeanphilippe.bernardy (google mail) ./collections-api/collections-api.cabal:maintainer: jeanphilippe.bernardy (google mail) ./collections-api/dist/collections-api-0.4/collections-api.cabal:maintainer: jeanphilippe.bernardy (google mail) ./enumsets/enumsets.cabal:maintainer: jeanphilippe.bernardy (google mail) ./enumsets/dist/enumsets-0.4/enumsets.cabal:maintainer: jeanphilippe.bernardy (google mail) ./collections-avl/dist/collections-avl-0.4/collections-avl.cabal:maintainer: jeanphilippe.bernardy (google mail) ./collections-avl/collections-avl.cabal:maintainer: jeanphilippe.bernardy (google mail) ./Data-Trie-General/Data-Trie-General.cabal:maintainer: http://homepages.nildram.co.uk/~ahey/em.png * Then I think the next step would be to remove whatever you've forked from the collections repo, & change the dependencies to depend on yours. But this assumes, I guess, that your versions haven't diverged too awfully far for the dependencies to fail. (So which ones are you maintaining, again?)
With regard to the maintenance state of packages in hackage, I think it's fine to have dead/dormant/"looking for new owner" packages archived there, just so long as it's clear to users that this is the case (anyone who finds it useful enough to care about it's maintainance can always take over ownership if they want).
See my other email. To expand on my thoughts there, Hackage could add a warning if there is no maintainer field, show a maintainer entry on the webpage anyway but with the default author being one Mr. "Unmaintained". On a side note, I happened to run all my local repositories through find/grep, and I see that there are two examples of "maintainer: none"! Which supports my contention about variants, and I will amusedly note, outweighs the single usage of "maintainer: Unmaintained".
As it happens I think I probably will keep maintaining the AVL stuff after all as the generalised tries package Jamie Brandon is working on will probably have a dependency on it.
Regards -- Adrian Hey
-- gwern DI VIP J2 AFSPC detection STEEPLEBUSH DES chosen DDR&E RUOP