IRC_Meetings: ghc-2008-07-16.log

File ghc-2008-07-16.log, 16.0 KB (added by igloo, 9 years ago)

First meeting, 2008-07-16, 4pm UK time

1<JaffaCake>     I pronounce the first GHC meeting open :)
2<JaffaCake>     welcome everyone
3<nominolo>      \o/
4<JaffaCake>     so what would you like to talk about? :)
5<Igloo> Good to see ghcbot made it
6<JaffaCake>     hehe
7<nominolo>      who else is present?
8<BSP_>          hey there :)
9*               waern is
10<BSP_>          did anyone announce this in #haskell?
11<JaffaCake>     good idea
12*               thorkilnaur_ is present
13                TD (n=tmdubui@ has joined #ghc
14                bwr_ (n=bwr@ has joined #ghc
15                dmwit (n=dmwit@ has joined #ghc
16                TD is now known as TomM1
17                xerox (n=xerox@unaffiliated/xerox) has joined #ghc
18                mauke ( has joined #ghc
19<JaffaCake>     welcome folks
20<JaffaCake>     so a good place to start is probably
21<lambdabot>     Title: Status/Releases - GHC - Trac
22                lilachaze (n=tla@kde/lilachaze) has joined #ghc
23<JaffaCake>     that's our high-level plan for 6.10
24                seafood ( has joined #ghc
25<dcoutts>       I'd like to push for HLP shipping some time after 6.10, not ages but perhaps a week or so
26<nominolo>      will that suffice?
27<dcoutts>       if the HLP starts small enough
28<Igloo>         The plan is for the first HLP release to be very small, so it ought to
29<dcoutts>       as it grows we'll need more time, since there will be more maintainers involved
30<nominolo>      ie., it'll be enough to update the .cabal files, but not for integration testing
31<Igloo>         Perhaps even a subset of extralibs
32<JaffaCake>     will there be another HLP release in the 6.10 timeframe?
33<dcoutts>       JaffaCake: yes
34<Igloo>         (plus happy, alex etc)
35<dcoutts>       ideally we would do time-based releases using whatever is the current ghc at the time
36<JaffaCake>     so it's likely that when 6.10 is released, many packages outside the HLP won't work
37<nominolo>      is the plan to have independent releases?
38<dcoutts>       nominolo: that's what I am arguing for
39<nominolo>      dcoutts: seems right to me
40<dcoutts>       my example is Gtk+ and GNOME
41<nominolo>      well, GNOME seems overly conservative in what it includes, but that's independent of the release process, i guess
42<JaffaCake>     I think this is a good plan, but it's a significant shift in the way we do things
43<JaffaCake>     GHC moves from being central to being a component
44<byorgey>       sorry, what's HLP?
45<nominolo>      Haskell Library Platform
47<lambdabot>     Title: Haskell Platform - HaskellWiki
48<byorgey>       ah, thanks
49<nominolo>      ie, Haskell's Batteries Included
50<nominolo>      dcoutts: do you have any thoughts on how to achieve QA?
51<JaffaCake>     perhaps if things like alex, haddock etc. are included it should be just HP
52<dcoutts>       nominolo: yes, using hackage
53<dcoutts>       so we don't have that infrastructure yey
54<dcoutts>       yet, but it's vital in the future to grow the platform and get decent testing
55                mib_ae57sc (i=8afbf104@gateway/web/ajax/ has joined #ghc
56<dcoutts>       otherwise it takes release managers too long and people burn out
57<nominolo>      i wouldn't mind if the packages in the HP may be a bit outdated
58<JaffaCake>     looking down that list on the wiki there's some duplication
59<mib_ae57sc>    ndm appears (with some ridiculous nickname)
60<nominolo>      dons_: what is monad-lib?
61<Igloo>         It is designed to replace mtl, I think
62<nominolo>      i couldn't find it on hackage
63<dcoutts>       Igloo and I think that current list of the HP wiki page is far far too big
64<dcoutts>       of/on
65<nominolo>      agreed
66<JaffaCake>     yes, definitely
67<nominolo>      but it should grow as quickly as QA allows
68<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
69<dcoutts>       nominolo: right, so hackage infrastructure is vital there
70<Igloo>         nominolo:
71<lambdabot>     Title: HackageDB: monadLib-3.4.4,
72<nominolo>      well, the list aims to compete with python, but i think we're not there yet
73<dcoutts>       I should note that lemmih, eelco and I have started hacking on a new hackage-server prototype
74<dcoutts>       based on happs
75<Igloo>         Yeah, I think that something like "extralibs - the OpenGL family + the obvious tools" makes sense
76<dcoutts>       which we hope to be able to extend with the kind of package QA features we all want
77<nominolo>      dcoutts: also short release cycles (say 3 months) help taking pressure off people's shoulders
78<dcoutts>       nominolo: GNOME uses 6month cycles with two or three minor updates inbetween
79<dcoutts>       and that seems to work pretty well
80<Igloo>         But we also need to think about what we require of HP libraries. e.g. the network package is unmaintained at the moment
81<sclv_>         one issue is that lots of the proposed hlp requires other things to be installed to bind to.
82<JaffaCake>     network is officially unmaintained, but in practice we do apply fixes
83<dcoutts>       sclv_: indeed, the list of foreign deps would have to be clear
84<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"
85<nominolo>      hm, does have galois have some internal replacement lying around which they could publish? :)
86<mib_ae57sc>    so i think that's what we should be wanting as a network
87                mib_ae57sc is now known as ndm
88                BMeph ( has joined #ghc
89<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)
90<nominolo>      claus: do we have up-to-date documentation?
91<ndm>           claus: i strongly disagree, OpenGL is completely ridiculous to have in HLP
92<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.
93<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
94<ndm>           i think it makes up ~70% of the WinHugs distro
95<ndm>           i'd say gtk2hs was a much better idea than opengl, and i think even that should be a no
96<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
97<ndm>           is opengl cabal install'able?
98<Igloo>         Yes
99<dcoutts>       where as gtk2hs is not, so is not yet a candidate
100<claus>         btw, core system editline does not seem to exist for windows ghc
101<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
102<Igloo>         claus: Right, we use the Windows built-in terminal editting on Windows
103<claus>         nominolo: the haddocks? only the pre-wiki web pages have gathered dust, and there's a wiki alternative
104<nominolo>      claus: ah, the homepage now redirects to the wiki
105<nominolo>      this was confusing
106<sclv_>         hmm... on the Network thing, is network-bytestring under active development?
107<nominolo>      ok, so how will the H(L)P selection process continue?
108<sclv_>         There should be a list, or it should be taken to libraries (which isn't quite suited by charter for it), no?
109<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
110<dcoutts>       nominolo: my suggestion is to start small with uncontroversial stuff
111<dcoutts>       and then agree how we decide on additions
112<ndm>           does HLP want to be small, or big? that's what i am not sure of
113<dcoutts>       what quality and review revirements we ask for
114<nominolo>      ndm: big, eventully;  small, for now
115<dcoutts>       ndm: start small, grow to cover "batteries included" scope
116<ndm>           cabal-install means HLP is not so important
117<dcoutts>       ndm: it's not about ease of distribution
118<ndm>           and can things be removed?
119<nominolo>      ndm: yes
120<ndm>           i think they should be :)
121<dcoutts>       it's about making things work together well, high quality, recommending stuff to people who do not know how to pick
122<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
123<nominolo>      ndm: the problem with cabal-install, though is, that a hackage package might not work so well
124<ndm>           Igloo: if its about making choices, then what if two people implement heaps? do we say yes to both?
125<ndm>           i worry that hackage will become the place for the junk
126<JaffaCake>     Igloo: but to keep things sane, one requirement should be that the package is useful to a reasonable number of people
127<ndm>           i also suggest that the package has been available for a while
128<dcoutts>       ndm: hackage is indeed a simmering big pile of duplication, that's fine. The HLP is supposed to be reviewed.
129<dcoutts>       JaffaCake: and we probably want some criteria about duplication
130<ndm>           dcoutts, yes, which means the criteria has to be more objective than purely technical
131<dcoutts>       ndm: sure
132<dcoutts>       again, my main recommendation here is to read what GNOME does
133<JaffaCake>     dcoutts: yes, which is where it gets difficult... network vs. network-bytestring for example
134<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
135<TomM1>         I think duplication should be avoided in general.
136<dcoutts>       they have a pretty good system for reviewing and accepting (and deprecating) packages
137<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
138<Igloo>         Anyone building HLP is going to have to use an automated tool anyway
139<allbery_b>     hackage, whcih was designed to be like cpan, ends up being like cpan; film at eleven
140<TomM1>         dcoutts: gnome criteria link?
141<sclv_>         How will HLP be released -- like extralibs is now?
142<TomM1>         It would be neat just to have a set of package names that cabal-install will be applied to.
143<sclv_>         Or as another single seperate bundle with a single makefile that just cabal-installs all the subdirs?
144<TomM1>         Naturally, distros would provide binary packages of the libraries/tools.
145<dcoutts>       TomM1: right, that's what a GNOME release is basically, a set of tarballs
146<Igloo>         sclv_: For what platform?
147<nominolo>      ndm: that's why the admission process should be formalised
148<dcoutts>       so our system would be a set of package versions on hackage, perhaps with a versioned meta-package
149<sclv_>         Igloo: in general I mean, not for the specialized distros...
150<nominolo>      ndm: and automated as much as possible
151<Igloo>         sclv_: Well, it'll vary depending on the platform
152<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
153<dcoutts>       TomM1: the docs seem to have been moved around, but start looking here
154<lambdabot>     Title: ReleasePlanning - GNOME Live!
155<sclv_>         Igloo: I mean like the "authoritative" release, not the platform specialized one.
156<dcoutts>       TomM1: I'll try and find something more specific
157                bringert ( has joined #ghc
158<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?
159<Igloo>         There might be an hlp package too, that just depends on everything else
160                jsnx ( has joined #ghc
161<JaffaCake>     right, we should be able to just 'cabal install hlp-1.0'
162<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.
163<JaffaCake>     Igloo: we might need to use GHC's Windows installer to ship the first HLP, building a new Windows installer is hard
164<ndm>           i'd suggest HLP just comes with GHC, and with Hugs
165<Igloo>         JaffaCake: Can't we have the HLP installer run the GHC installer?
166<ndm>           (on windows at least)
167<dcoutts>       for windows yes, we'd want a single installer with GHC and HLP
168<JaffaCake>     yes, but would the GHC installer install the HLP packages?
169<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...
170<ndm>           and a single installer with Hugs and HLP
171<dcoutts>       though there may be a separate GHC installer without the batteries
172<dcoutts>       sclv_: indeed
173<dcoutts>       sclv_: eg in gentoo we have all the separate gnome packages and one 'gnome' meta-package for user convenience
174<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
175<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?
176<Igloo>         JaffaCake: No, the HLP installer would run the GHC installer and then install all the HLP packages
177<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
178<JaffaCake>     Igloo: ok, so you're proposing building a new HLP installers
179<Igloo>         Right
180                gbeshers (n=gbeshers@nat/redhat-us/x-ff6276b77519e80f) has joined #ghc
181<ndm>           i think one combined GHC+HLP is much easier, more robust, and less likely to go wrong, on Windows
182<dcoutts>       ndm: yes
183<sclv_>         claus -- then cabal install really would be replacing distros!
184<ndm>           there is no point splitting them unless you really can combine GHC 6.10.2 with HLP 3.4
185<ndm>           which is really really unlikely!
186<Igloo>         That's a real pain to do, in practice
187<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.
188<Igloo>         Especially if you want to make an updated HLP with the same GHC
189<ndm>           how often will new .1 GHC releases come out?
190<JaffaCake>     separate binary tarballs are tricky, because they have very tight dependencies on the particular GHC build
191<ndm>           if its every 3 months, say, then the benefits of a new HLP is less
192<ndm>           gtk2hs has fairly substantial problems with GHC version skew, and this would be much worse
193<dcoutts>       ndm: that's because it's not automated
194<dcoutts>       automation is vial here
195<sclv_>         For windows, the installer could be updated with new HLPs more often than every GHC release...
196<Igloo>         ndm: People wouldn't update to a new GHC, though, they'd update to a new GHC+HLP
197<dcoutts>       ndm: automated testing and if you want windows installers then those must be automated too
198<ndm>           Igloo: yes, i think that's fair though
199<ndm>           dcoutts, yes!
201<lambdabot>     Title: ReleasePlanning/ModuleProposing - GNOME Live!
202<dcoutts>       TomM1: ^^
203<TomM1>         Thanks
204<dcoutts>       and see also the stuff about time-based releases
205<dcoutts>       where everyone knows the schedule months in advance
206<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?
207<dcoutts>       claus: windows is an odd case because it does not have a binary package manager
208<jsnx>          claus: i think you would also need to start cryptographically signing things
209<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?
210<JaffaCake>     I have to disappear, later folks
211<dcoutts>       taraa JaffaCake
212<nominolo>      dcoutts: i guess for windows (and osx) a big binary installer should be fine
213<nominolo>      afaik, that's what python does
214<dons_>         monadLib is on hackage.
215<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)
216<nominolo>      dons_: i was looking for monad-lib instead of monadLib
217<claus>         jsnx: ah, yes, there is that.