IRC_Meetings: ghc-2008-07-16.log

<JaffaCake>     I pronounce the first GHC meeting open :)
<JaffaCake>     welcome everyone
<nominolo>      \o/
<JaffaCake>     so what would you like to talk about? :)
<Igloo> Good to see ghcbot made it
<JaffaCake>     hehe
<nominolo>      who else is present?
<BSP_>          hey there :)
*               waern is
<BSP_>          did anyone announce this in #haskell?
<JaffaCake>     good idea
*               thorkilnaur_ is present
                TD (n=tmdubui@144.51.26.41) has joined #ghc
                bwr_ (n=bwr@64.47.121.98) has joined #ghc
                dmwit (n=dmwit@64.80.131.48) has joined #ghc
                TD is now known as TomM1
                xerox (n=xerox@unaffiliated/xerox) has joined #ghc
                mauke (i=mauke@rm-f.net) has joined #ghc
<JaffaCake>     welcome folks
<JaffaCake>     so a good place to start is probably http://hackage.haskell.org/trac/ghc/wiki/Status/Releases
<lambdabot>     Title: Status/Releases - GHC - Trac
                lilachaze (n=tla@kde/lilachaze) has joined #ghc
<JaffaCake>     that's our high-level plan for 6.10
                seafood (n=sseefrie@180.218.233.220.exetel.com.au) has joined #ghc
<dcoutts>       I'd like to push for HLP shipping some time after 6.10, not ages but perhaps a week or so
<nominolo>      will that suffice?
<dcoutts>       if the HLP starts small enough
<Igloo>         The plan is for the first HLP release to be very small, so it ought to
<dcoutts>       as it grows we'll need more time, since there will be more maintainers involved
<nominolo>      ie., it'll be enough to update the .cabal files, but not for integration testing
<Igloo>         Perhaps even a subset of extralibs
<JaffaCake>     will there be another HLP release in the 6.10 timeframe?
<dcoutts>       JaffaCake: yes
<Igloo>         (plus happy, alex etc)
<dcoutts>       ideally we would do time-based releases using whatever is the current ghc at the time
<JaffaCake>     so it's likely that when 6.10 is released, many packages outside the HLP won't work
<nominolo>      is the plan to have independent releases?
<dcoutts>       nominolo: that's what I am arguing for
<nominolo>      dcoutts: seems right to me
<dcoutts>       my example is Gtk+ and GNOME
<nominolo>      well, GNOME seems overly conservative in what it includes, but that's independent of the release process, i guess
<JaffaCake>     I think this is a good plan, but it's a significant shift in the way we do things
<JaffaCake>     GHC moves from being central to being a component
<byorgey>       sorry, what's HLP?
<nominolo>      Haskell Library Platform
<Igloo>         http://haskell.org/haskellwiki/Haskell_Platform
<lambdabot>     Title: Haskell Platform - HaskellWiki
<byorgey>       ah, thanks
<nominolo>      ie, Haskell's Batteries Included
<nominolo>      dcoutts: do you have any thoughts on how to achieve QA?
<JaffaCake>     perhaps if things like alex, haddock etc. are included it should be just HP
<dcoutts>       nominolo: yes, using hackage
<dcoutts>       so we don't have that infrastructure yey
<dcoutts>       yet, but it's vital in the future to grow the platform and get decent testing
                mib_ae57sc (i=8afbf104@gateway/web/ajax/mibbit.com/x-c6f9a82feee1ae2f) has joined #ghc
<dcoutts>       otherwise it takes release managers too long and people burn out
<nominolo>      i wouldn't mind if the packages in the HP may be a bit outdated
<JaffaCake>     looking down that list on the wiki there's some duplication
<mib_ae57sc>    ndm appears (with some ridiculous nickname)
<nominolo>      dons_: what is monad-lib?
<Igloo>         It is designed to replace mtl, I think
<nominolo>      i couldn't find it on hackage
<dcoutts>       Igloo and I think that current list of the HP wiki page is far far too big
<dcoutts>       of/on
<nominolo>      agreed
<JaffaCake>     yes, definitely
<nominolo>      but it should grow as quickly as QA allows
<dcoutts>       I think we agreed that we'd prefer just the existing extralibs (or slightly less in places) plus tools like happy, haddock, alex, c2hs
<dcoutts>       nominolo: right, so hackage infrastructure is vital there
<Igloo>         nominolo: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/monadLib
<lambdabot>     Title: HackageDB: monadLib-3.4.4, http://tinyurl.com/5ku9e4
<nominolo>      well, the list aims to compete with python, but i think we're not there yet
<dcoutts>       I should note that lemmih, eelco and I have started hacking on a new hackage-server prototype
<dcoutts>       based on happs
<Igloo>         Yeah, I think that something like "extralibs - the OpenGL family + the obvious tools" makes sense
<dcoutts>       which we hope to be able to extend with the kind of package QA features we all want
<nominolo>      dcoutts: also short release cycles (say 3 months) help taking pressure off people's shoulders
<dcoutts>       nominolo: GNOME uses 6month cycles with two or three minor updates inbetween
<dcoutts>       and that seems to work pretty well
<Igloo>         But we also need to think about what we require of HP libraries. e.g. the network package is unmaintained at the moment
<sclv_>         one issue is that lots of the proposed hlp requires other things to be installed to bind to.
<JaffaCake>     network is officially unmaintained, but in practice we do apply fixes
<dcoutts>       sclv_: indeed, the list of foreign deps would have to be clear
<mib_ae57sc>    network isn't really good enough, quite a lot of people use the TagSoup downloadFile, even though its explicitly marked as "very unreliable"
<nominolo>      hm, does have galois have some internal replacement lying around which they could publish? :)
<mib_ae57sc>    so i think that's what we should be wanting as a network
                mib_ae57sc is now known as ndm
                BMeph (n=black@wsip-70-167-169-169.sd.sd.cox.net) has joined #ghc
<claus>         Igloo: please keep OpenGL in HLP (solid, showcase potential, has outlived all competitors, is a good test/demo of FFI as HLP replaces extralibs)
<nominolo>      claus: do we have up-to-date documentation?
<ndm>           claus: i strongly disagree, OpenGL is completely ridiculous to have in HLP
<sclv_>         My feeling is that anything with foreign deps with maybe a few exceptions can be "blessed" but shouldn't come with any sort of single libs package.
<Igloo>         claus: OpenGL takes a huge amount of time to build, and I doubt is used very much. I think we should keep things small, quick and easy for HLP v1.0
<ndm>           i think it makes up ~70% of the WinHugs distro
<ndm>           i'd say gtk2hs was a much better idea than opengl, and i think even that should be a no
<dcoutts>       claus: if it's not in the first release I'm sure it can make it into a later one, we expect to grow it
<ndm>           is opengl cabal install'able?
<Igloo>         Yes
<dcoutts>       where as gtk2hs is not, so is not yet a candidate
<claus>         btw, core system editline does not seem to exist for windows ghc
<ndm>           i think given the small numbers of users, and the cabal-install'ability, makes it hard to justify in a core set of libraries
<Igloo>         claus: Right, we use the Windows built-in terminal editting on Windows
<claus>         nominolo: the haddocks? only the pre-wiki web pages have gathered dust, and there's a wiki alternative
<nominolo>      claus: ah, the homepage now redirects to the wiki
<nominolo>      this was confusing
<sclv_>         hmm... on the Network thing, is network-bytestring under active development?
<nominolo>      ok, so how will the H(L)P selection process continue?
<sclv_>         There should be a list, or it should be taken to libraries (which isn't quite suited by charter for it), no?
<claus>         igloo, ndm: with the demise of bare-bones HGL, OpenGL is the only survivor in terms of graphics, and Haskell's binding is better than most other languages', so in terms of "batteries" included, it seems an obvious, if often neglected choice
<dcoutts>       nominolo: my suggestion is to start small with uncontroversial stuff
<dcoutts>       and then agree how we decide on additions
<ndm>           does HLP want to be small, or big? that's what i am not sure of
<dcoutts>       what quality and review revirements we ask for
<nominolo>      ndm: big, eventully;  small, for now
<dcoutts>       ndm: start small, grow to cover "batteries included" scope
<ndm>           cabal-install means HLP is not so important
<dcoutts>       ndm: it's not about ease of distribution
<ndm>           and can things be removed?
<nominolo>      ndm: yes
<ndm>           i think they should be :)
<dcoutts>       it's about making things work together well, high quality, recommending stuff to people who do not know how to pick
<Igloo>         ndm: I think if someone is willing to maintain a package and keep it meeting whatever criteria we decide to require, then we shouldn't refuse it
<nominolo>      ndm: the problem with cabal-install, though is, that a hackage package might not work so well
<ndm>           Igloo: if its about making choices, then what if two people implement heaps? do we say yes to both?
<ndm>           i worry that hackage will become the place for the junk
<JaffaCake>     Igloo: but to keep things sane, one requirement should be that the package is useful to a reasonable number of people
<ndm>           i also suggest that the package has been available for a while
<dcoutts>       ndm: hackage is indeed a simmering big pile of duplication, that's fine. The HLP is supposed to be reviewed.
<dcoutts>       JaffaCake: and we probably want some criteria about duplication
<ndm>           dcoutts, yes, which means the criteria has to be more objective than purely technical
<dcoutts>       ndm: sure
<dcoutts>       again, my main recommendation here is to read what GNOME does
<JaffaCake>     dcoutts: yes, which is where it gets difficult... network vs. network-bytestring for example
<Igloo>         Well, I don't feel strongly about it, but I can forsee arguments about where the line is drawn. And if someone is going to go to the effort of maintaining something I don't see that including it in HLP causes us problems
<TomM1>         I think duplication should be avoided in general.
<dcoutts>       they have a pretty good system for reviewing and accepting (and deprecating) packages
<ndm>           i worry that developers will write libraries, and all developers believe their library is really useful, amazingly robust and should be in - we don't want to upset these people
<Igloo>         Anyone building HLP is going to have to use an automated tool anyway
<allbery_b>     hackage, whcih was designed to be like cpan, ends up being like cpan; film at eleven
<TomM1>         dcoutts: gnome criteria link?
<sclv_>         How will HLP be released -- like extralibs is now?
<TomM1>         It would be neat just to have a set of package names that cabal-install will be applied to.
<sclv_>         Or as another single seperate bundle with a single makefile that just cabal-installs all the subdirs?
<TomM1>         Naturally, distros would provide binary packages of the libraries/tools.
<dcoutts>       TomM1: right, that's what a GNOME release is basically, a set of tarballs
<Igloo>         sclv_: For what platform?
<nominolo>      ndm: that's why the admission process should be formalised
<dcoutts>       so our system would be a set of package versions on hackage, perhaps with a versioned meta-package
<sclv_>         Igloo: in general I mean, not for the specialized distros...
<nominolo>      ndm: and automated as much as possible
<Igloo>         sclv_: Well, it'll vary depending on the platform
<Igloo>         e.g. for Windows it might make sense to have a single binary installer (perhaps also including GHC's installer?), while for Debian everything will be in separate debs
<dcoutts>       TomM1: the docs seem to have been moved around, but start looking here http://live.gnome.org/ReleasePlanning
<lambdabot>     Title: ReleasePlanning - GNOME Live!
<sclv_>         Igloo: I mean like the "authoritative" release, not the platform specialized one.
<dcoutts>       TomM1: I'll try and find something more specific
                bringert (n=bringert@dhcp-195-117.nomad.chalmers.se) has joined #ghc
<sclv_>         ok so for debian it's still not like I could choose to install the "hlp" in particular -- they'd just be packages blessed for being bundled up?
<Igloo>         There might be an hlp package too, that just depends on everything else
                jsnx (n=jsnx@dsl081-067-241.sfo1.dsl.speakeasy.net) has joined #ghc
<JaffaCake>     right, we should be able to just 'cabal install hlp-1.0'
<sclv_>         If things like the mtl are going to be in the basic hlp it'll need to be only one or two commands/clicks away.
<JaffaCake>     Igloo: we might need to use GHC's Windows installer to ship the first HLP, building a new Windows installer is hard
<ndm>           i'd suggest HLP just comes with GHC, and with Hugs
<Igloo>         JaffaCake: Can't we have the HLP installer run the GHC installer?
<ndm>           (on windows at least)
<dcoutts>       for windows yes, we'd want a single installer with GHC and HLP
<JaffaCake>     yes, but would the GHC installer install the HLP packages?
<sclv_>         So I know we have build reporting gradually getting added to the cabal/hackage infrastructure. the HLP seems also like something that really adds some motivation for getting the popularity stats / depreciation markings done right...
<ndm>           and a single installer with Hugs and HLP
<dcoutts>       though there may be a separate GHC installer without the batteries
<dcoutts>       sclv_: indeed
<dcoutts>       sclv_: eg in gentoo we have all the separate gnome packages and one 'gnome' meta-package for user convenience
<JaffaCake>     yes, as a first step we can release GHC 6.10.1 with just the bootlibs, and later produce new installers with the rest of HLP
<claus>         couldn't cabal install support platform-specific binary tarballs, as an alternative to build-from-source packages? so one could 'cabal install hlp-bin-1.0' and it would see whether there was a windows/mac/whatever binary tarball matching your platform?
<Igloo>         JaffaCake: No, the HLP installer would run the GHC installer and then install all the HLP packages
<dcoutts>       JaffaCake: then the Q is, if you should make a windows installed for just ghc-6.10.1 or just wait for the combined thing
<JaffaCake>     Igloo: ok, so you're proposing building a new HLP installers
<Igloo>         Right
                gbeshers (n=gbeshers@nat/redhat-us/x-ff6276b77519e80f) has joined #ghc
<ndm>           i think one combined GHC+HLP is much easier, more robust, and less likely to go wrong, on Windows
<dcoutts>       ndm: yes
<sclv_>         claus -- then cabal install really would be replacing distros!
<ndm>           there is no point splitting them unless you really can combine GHC 6.10.2 with HLP 3.4
<ndm>           which is really really unlikely!
<Igloo>         That's a real pain to do, in practice
<dcoutts>       claus: yes, I don't see the need for binaries with cabal-install. I think that's best left to distros and windows/mac installers etc.
<Igloo>         Especially if you want to make an updated HLP with the same GHC
<ndm>           how often will new .1 GHC releases come out?
<JaffaCake>     separate binary tarballs are tricky, because they have very tight dependencies on the particular GHC build
<ndm>           if its every 3 months, say, then the benefits of a new HLP is less
<ndm>           gtk2hs has fairly substantial problems with GHC version skew, and this would be much worse
<dcoutts>       ndm: that's because it's not automated
<dcoutts>       automation is vial here
<sclv_>         For windows, the installer could be updated with new HLPs more often than every GHC release...
<Igloo>         ndm: People wouldn't update to a new GHC, though, they'd update to a new GHC+HLP
<dcoutts>       ndm: automated testing and if you want windows installers then those must be automated too
<ndm>           Igloo: yes, i think that's fair though
<ndm>           dcoutts, yes!
<dcoutts>       http://live.gnome.org/ReleasePlanning/ModuleProposing
<lambdabot>     Title: ReleasePlanning/ModuleProposing - GNOME Live!
<dcoutts>       TomM1: ^^
<TomM1>         Thanks
<dcoutts>       and see also the stuff about time-based releases
<dcoutts>       where everyone knows the schedule months in advance
<claus>         dcoutts: ever since the GHC build process allowed, I've been using binary tarballs instead of installers (on windows); that might be easier to automate for libs than installers? one only needs the HLP libs relocatable, and built with the proper GHC, and synchronisation is what HLP is about, isn't it?
<dcoutts>       claus: windows is an odd case because it does not have a binary package manager
<jsnx>          claus: i think you would also need to start cryptographically signing things
<dcoutts>       I guess the other question is, since they're a bunch of packages meant to work together why bother with separate binary packages rather than one big windows installer?
<JaffaCake>     I have to disappear, later folks
<dcoutts>       taraa JaffaCake 
<nominolo>      dcoutts: i guess for windows (and osx) a big binary installer should be fine
<nominolo>      afaik, that's what python does
<dons_>         monadLib is on hackage.
<claus>         dcoutts: ok, if you have someone/something building those installers; with binary tarballs, you simply tar up a successful build (as the nightly builds used to do)
<nominolo>      dons_: i was looking for monad-lib instead of monadLib
<claus>         jsnx: ah, yes, there is that.