Hello Don, I didn't write all of them, there are other authors involved so I can't say for sure what their plans may be. But I'm pretty sure that if they're still interested and thought the code fit for release they'd put it in Hackage themselves. Regards -- Adrian Hey Don Stewart wrote:

As author Adrian, you can ask to have them removed.

Gwern: do not upload other people's packages, if they're active! It is impolite, and leads to far too much broken code.

In particular, doing random forks of existing packages with their own matainers *is not helpful* -- it just leads to broken, unmaintained code.

Adrian, as these packages simply fork needlessly, or aren't of suitable quality, I think you can ask Ross to remove them.

ahey:

...

Hello folks in general and GwernBranwen in particular :-)

I don't want to seem ungratful, but I see a lot of the old "new" collections repository has been uploaded to Hackage as separate packages but it really shouldn't be there IMHO. AFAIK most of this stuff has never been properly tested and is in any case not being actively worked on or maintained any more.

AvlTree and COrdering have been thoroughly tested and are already in Hackage as separate packages. These are not being worked on or maintained by anyone either, but they are the latest official releases that anyone interested should use.

The generalised trie stuff is what Jamie Brandon is working on for his GSOC project.

The relevant packages are:

Data-Tree-AVL 0.4 Data-COrdering 0.4 Data-Trie-General 0.4 collections-base-instances 0.4 collections-rangedsets-instances 0.4 collections-api 0.4 enumsets 0.4 collections-avl 0.4 Data-Trie-General-OrdGT 0.4 collections 0.4

-- Don

______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

On Thu, 2008-06-19 at 01:31 +0100, Ross Paterson wrote:

On Wed, Jun 18, 2008 at 01:11:25PM -0700, Don Stewart wrote:

...

As author Adrian, you can ask to have them removed.

Gwern: do not upload other people's packages, if they're active! It is impolite, and leads to far too much broken code.

In particular, doing random forks of existing packages with their own matainers *is not helpful* -- it just leads to broken, unmaintained code.

I don't mind forks, as long as they have a maintainer and a different name.

My problem with these packages is that they specify maintainers, but the uploaded versions appear not to have been created by the named maintainers.

If a package names a maintainer, I think we should be able to assume that whatever was uploaded is that person's approved version, packaging and all.

I agree. I think we should get round to writing this down as a hackage policy and getting a quick show of hands on this list. Duncan

gwern0:

On 2008.06.18 13:11:25 -0700, Don Stewart scribbled 1.4K characters:

...

As author Adrian, you can ask to have them removed.

Gwern: do not upload other people's packages, if they're active! It is impolite, and leads to far too much broken code.

In particular, doing random forks of existing packages with their own matainers *is not helpful* -- it just leads to broken, unmaintained code.

Adrian, as these packages simply fork needlessly, or aren't of suitable quality, I think you can ask Ross to remove them. ...

-- Don

I'd like to note that these were not 'random forks'. JPB, the collections maintainer, apparently he split them up last year, listing himself and Hey as maintainers of various packages. All I did was fix up the usual Cabal breakage and re-upload when he accepted my patches; otherwise they are as they were.

Why not let the package maintainer upload? Especially since we've now duplicate avltree and cordering libraries, this seems to not have been a useful move. -- Don

For what it's worth, I'm the one who suggested to Gwern that he update the cabal stuff for collections. Someone had remarked that there was no good way to make use of various collection types in the standard libraries, and I knew that the collections package on hackage took steps toward rectifying that. But, it didn't build on 6.8, due to what looked like a split-base issue. I knew Gwern had experience fixing up cabal-related stuff, so I told him he might want to try getting them fixed.

FWIW (again) : * I think collections-api is a good base to give a uniform API to a lot of data structures on hackage. - It uses FD style though, so one might want to adapt it to AT soon. (I tried with GHC 6.8 but support was too buggy). - In particular, it can be useful to write a polymorphic testing and benchmarking framework. * I have no time to maintain collections. As Adrian said before, this is an unpaid, thankless job, so my motivation went downhill since I started the project. * I did not remember that Adrian had reclaimed some parts and uploaded them separately. Corresponding code in the collections repo should be removed and the rest adapted to use Adrian's version. * Hence, I gave a "don't care" signal to Gwern when he proposed uploading to hackage. We already discussed this before, but that repository can be considered orphaned. I'll give pointers to anybody interested in adopting it. Cheers, JP.

ross:

On Fri, Jun 20, 2008 at 10:01:29AM +0200, Jean-Philippe Bernardy wrote:

...

We already discussed this before, but that repository can be considered orphaned. I'll give pointers to anybody interested in adopting it.

Thanks for the clarification, Jean-Philippe.

On the broader issue, personally I'd prefer not to have non-maintained packages on hackageDB (because their presence lowers people's expectations of the whole collection) but others disagree on that point. If we must have them, they ought not to be marked as maintained. It's not fair on users, or on the person named as maintainer.

Perhaps if the .cabal files for orphaned packages could be marked as, say: maintainer: unmaintained or maintainer: orphaned This might alleviate some problems (a future hackage could filter unmaintained packages). Gwern, would that work for you, for these library salvaging efforts? -- Don

Gwern Branwen wrote:

On 2008.06.20 11:49:17 -0700, Don Stewart scribbled 0.9K characters:

...

ross:

...

On Fri, Jun 20, 2008 at 10:01:29AM +0200, Jean-Philippe Bernardy wrote:

...

We already discussed this before, but that repository can be considered orphaned. I'll give pointers to anybody interested in adopting it. Thanks for the clarification, Jean-Philippe.

On the broader issue, personally I'd prefer not to have non-maintained packages on hackageDB (because their presence lowers people's expectations of the whole collection) but others disagree on that point. If we must have them, they ought not to be marked as maintained. It's not fair on users, or on the person named as maintainer. Perhaps if the .cabal files for orphaned packages could be marked as, say:

maintainer: unmaintained

or

maintainer: orphaned

This might alleviate some problems (a future hackage could filter unmaintained packages).

Gwern, would that work for you, for these library salvaging efforts?

-- Don

This *would* work for me; however, there is a reason I haven't done this or something like it before (and instead simply omitted the maintainer: field whenever I thought something was unmaintained).

Fundamentally, I feel that putting something like into the free-form text field is kind of abusing it, that there should be some more structured way. As you've already pointed out, when a package is unmaintained, what is the canonical machine-readable way of saying so?

We have such ways of specifying dependencies and tested-status, which is good

for cabal-install. But what about maintainedness? Is it "unmaintained"? "unsupported"? "Unsupported"? "orphaned"? "Orphaned"? I can tell you just from past experience with the stability: field* that people will use all those and more if we don't give them a clear and unambiguous restriction on what can be put in - and then how will Hackage programmatically filter out unmaintained stuff?

The status quo of not listing maintainer at least is programmatic - if there's

a maintainer field, it's maintained by the person listed; if not, not. We could formalize this a little bit. For example, the cabal tools see an omitted maintainer field as a problem, not as a valid choice, and Hackage does nothing based on an omission. These are relatively small tweaks, though. What's the alternative? some sort of data Maintainer = None | Maintained String? But how could you then make maintainer: backwards compatible...? Add an entirely new field? (maintained: True) But then we wouldn't see it in sufficiently wide-spread use to be usable for years and years.

* Which needs to be fixed for all the reasons I've listed here for

maintainer:; see http://hackage.haskell.org/trac/hackage/ticket/265. Here is another view: The use of a cabal field to indicate orphan seems wrong to me. The maintainer field in the cabal file currently indicates who was responsible for and interested in such things as bug reports and patches at the time of the release of that version of that package. The orphan state is associated with the package's basename, not any given version of the package. I think of "orphan" vs "non-orphan" as associated with promised future versions of the package. In an extreme case, the orphan status could change several times in a day. Things at this level of abstraction should be tracked by a future version of hackage. What expectations should a user have when a package: has an Author? has a Maintainer? is an orphan? is supported? is unsupported? -- Chris

At Mon, 23 Jun 2008 22:40:18 +0100, Duncan Coutts wrote:

Yes. I agree. It's not even necessarily the author themselves that would necessarily mark a package as obsolete or without maintainers or whatever.

On a slightly related note, I would be more likely to fix my broken packages on hackageDB, if hackageDB automatically sent me an email when a package breaks. j.

On Tue, 2008-06-24 at 19:01 +0100, Neil Mitchell wrote:

Hi

...

...

Yes. I agree. It's not even necessarily the author themselves that would necessarily mark a package as obsolete or without maintainers or whatever.

On a slightly related note, I would be more likely to fix my broken packages on hackageDB, if hackageDB automatically sent me an email when a package breaks.

Me too! Or when new warnings get added to the hackage system which would cause a warning on a new upload, or when haddock or GHC fails to build the package.

York University has a particularly effective way of ensuring everyone uses valid HTML, by sending an email once a week if there is any invalid HTML. Perhaps this would be going too far, but alerting maintainers to the problems would be handy.

Yes. Once our data on build outcomes is of sufficient quality to not just annoy everyone then I think we should have hackage email maintainers. At the moment we only check packages once at upload time and never again. Also even when they do fail, as often as not it's not really the package author's fault (eg diamond dep errors, missing C libs). Duncan

On 2008.06.20 17:06:28 +0100, Adrian Hey scribbled 1.2K characters:

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