[core libraries] List of core libraries

[Edward Kmett]

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 <ndmitchell at gmail.com> 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 <andygill at ku.edu> 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 <ekmett at gmail.com> 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 <
> hvriedel at gmail.com>
> > 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 at 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...
> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20141009/0fa10ba1/attachment.html>