Great. I think filepath could do with a bit of TLC, and I am happy to do that. There are lots of things that are looking a little crusty around the edges (I don't think the test suite will actually fail in Travis if there is an error, it refers to dead web pages, the README talks a lot about Yhc). I see Herbert and Ian before him have done a reasonable amount of work to keep it in a GHC'able state, and I wouldn't want to cause any difficulties there. So two main questions: * Where/how should I push changes? Should I start with pull requests to the filepath module? Should I clone it to ndmitchell and that become the official repo? Should I get added to the haskell group? * What's the integration with GHC? Does the filepath module get pulled directly into GHC source trees? I see it's in the GHC test suite - is that considered a good idea? I'm a fan of testing my packages to destruction outside the GHC tree, but if people think its valuable it can stay - my main worry is breaking the GHC test suite inadvertently by not updating the expected stdout (which Travis doesn't currently check). Thanks, Neil On Thu, Oct 9, 2014 at 11:16 PM, Edward Kmett wrote:

It is your library as much as you want it to be. As such you can consider yourself as the maintainer and under http://www.haskell.org/haskellwiki/Library_submissions

Changes that simply widen the API by adding new functions are a bit of a grey area. It's better to consult the community, because there may be useful feedback about (say) the order of arguments, or the name of the function, or whatnot. On the other hand few clients will actually break if you add a new function to the API. Use your judgment.

Here you have a pretty obvious combinator, with one obvious argument ordering I'd assume, so you should be able to do as you see fit.

The core libraries committee can help as much or as little as you want us to around filepath.

-Edward

On Thu, Oct 9, 2014 at 5:56 PM, Neil Mitchell wrote:

...

I did semi-hand the filepath library over to the Core libraries committee, it was just about 6 years before the committee formed so you probably don't have records of it, which is why libraries@ is listed as the author. I'm happy to take a more active role in maintaining it. In particular, I was intending to review/comment on https://github.com/haskell/filepath/pulls, and have the intention to add a bunch of patches (https://github.com/ndmitchell/shake/issues/174). Most of the patches are either obviously a good idea (fixing broken code) or improving the docs. The only one which could have any debate surrounding it is the introduction of a new operator -<.>. I don't want to debate that now, but it would be good to get clarification as to whether I should unilaterally add it, or should go through the libraries submission process, or ...

Thanks, Neil

On Tue, Sep 30, 2014 at 4:17 PM, Andrew Gill wrote:

...

All,

I’ve not touched hoc for quite a while. KU now has the resources to take ownership, if needed. It’s pretty stable, from what I understand, but could do with the an updated manual.

Andy Gill

On Sep 28, 2014, at 1:45 PM, Edward Kmett wrote:

Herbert:

Heretofore I'd been treating filepath as owned by Neil Mitchell, but that statement does sound like he's handed it off to the libraries process, which would make it a core-libraries issue if he doesn't want to deal with it.

I'm copying him on this thread to get his opinion.

I've also copied Andy Gill, to see if he has any opinions on the state of who owns update responsibility for hpc itself.

Andy, Neil: Thoughts?

Thomas: Thanks for forcing this issue to attention.

-Edward

On Sun, Sep 28, 2014 at 2:14 PM, Herbert Valerio Riedel wrote:

...

On 2014-09-28 at 19:40:25 +0200, Thomas Miedema wrote:

[...]

...

Ok, final question: What about filepath and hpc? Their .cabal files list libraries@haskell.org as maintainer, which usually means the Core Libraries Committee. Should filepath be added to that list, and the maintainer for both filepath and hpc be set to the Core Libraries Committee? If not, who maintains filepath?

This is supposed to be an answer, but rather additional data-points:

As far as filepath is concerned:

http://community.haskell.org/~ndm/filepath/

states

| The library is now part of the core Haskell libraries, and since GHC | 6.6.1 has been shipped with all major compilers. While I am the | original author, changes are now made through the library submissions | process.

as for Hpc, if you look at its changelog over at

http://git.haskell.org/packages/hpc.git/shortlog

it's been effectively maintained by GHC HQ for the last couple of years...