| At the moment, GHC releases are the main driver for the community to get
| to work on packaging. I think what Duncan is proposing is that we
| should change expectations around, so that the HLP's standardised
| regular release cycle becomes the main driver for packaging work, and
| that
On Mon, Jul 21, 2008 at 02:59:47PM +0100, Claus Reinke wrote:
Will there be buildbots, and a buildbot report and release cycle discussion
list for HLP, to help raise the standards of HLP beyond hackage toward
that of extralibs?
There will be whatever people set up! That all sounds great; if
[been on holiday - just catching up]
| So the point of this analogy is that the releases of ghc and the
| haskell platform should not be synchronised.
Does that make sense? ... we do need to release a HLP that works, say,
with GHC 6.10, at the same time that 6.10 comes out.
I disagree
On Mon, 2008-07-21 at 10:38 +0100, Malcolm Wallace wrote:
[been on holiday - just catching up]
Welcome back! :-)
| So the point of this analogy is that the releases of ghc and the
| haskell platform should not be synchronised.
Does that make sense? ... we do need to release a HLP
Malcolm Wallace wrote:
[been on holiday - just catching up]
| So the point of this analogy is that the releases of ghc and the
| haskell platform should not be synchronised.
Does that make sense? ... we do need to release a HLP that works, say,
with GHC 6.10, at the same time that 6.10
GNOME has managed to do this. They have regular 6 month time based
releases. Everyone knows in advance when the releases will be so nobody
complains that it should happen sooner (unless they get behind
schedule). They've managed to make the release process so smooth it's
almost boring. No
Malcolm.Wallace:
[been on holiday - just catching up]
| So the point of this analogy is that the releases of ghc and the
| haskell platform should not be synchronised.
Does that make sense? ... we do need to release a HLP that works, say,
with GHC 6.10, at the same time that 6.10
| So the point of this analogy is that the releases of ghc and the haskell
| platform should not be synchronised. The platform releases should follow
| the ghc releases.
The trouble is that you can't use a previous version of the Haskell Library
Platform with a new version of GHC. Because the
On Thu, Jul 10, 2008 at 3:15 AM, Ian Lynagh [EMAIL PROTECTED] wrote:
On Wed, Jul 09, 2008 at 03:35:30PM -0700, Donald Bruce Stewart wrote:
I'm very keen to have HLP in place by the 6.10 release. I've started
a wiki page here,
http://haskell.org/haskellwiki/Haskell_Platform
Great,
On Wed, 2008-07-09 at 15:35 -0700, Don Stewart wrote:
b) You and Duncan lead
The disadvantage of (a) is that it couples the release cycles.
Yes, that's a problem especially as we want to grow the platform (while
maintaining release quality and timeliness).
On the other hand, a
Don Stewart wrote:
simonpj:
Don, Duncan
| We need to do something about the Haskell library platform around the
| 6.10 release too. At least a list of libraries considered the
| an minimal platform for support by the distros.
Simon and Ian and I were discussing this yesterday. Could the
On Tue, Jul 8, 2008 at 10:55 PM, Don Stewart [EMAIL PROTECTED] wrote:
We'd want other things not in extralibs too (e.g. binary, json, feed,
tagsoup..)
The platform should look something like the python core libraries --
enough to get most common tasks done, and a minimal standard for a
| We probably don't want extralibs and the HLP.
|
| Are you willing to lead on this?
|
| We'd want other things not in extralibs too (e.g. binary, json, feed,
| tagsoup..)
Absolutely! I wasn't suggesting that HLP = current extralibs. Rather, we were
thinking that we could abolish extralibs in
simonpj:
| We probably don't want extralibs and the HLP.
|
| Are you willing to lead on this?
|
| We'd want other things not in extralibs too (e.g. binary, json, feed,
| tagsoup..)
Absolutely! I wasn't suggesting that HLP = current extralibs. Rather,
we were thinking that we could
On Wed, Jul 09, 2008 at 03:35:30PM -0700, Donald Bruce Stewart wrote:
I'm very keen to have HLP in place by the 6.10 release. I've started
a wiki page here,
http://haskell.org/haskellwiki/Haskell_Platform
Great, thanks Don!
Here are a few criteria that I think it might be worth
Don, Duncan
| We need to do something about the Haskell library platform around the
| 6.10 release too. At least a list of libraries considered the
| an minimal platform for support by the distros.
Simon and Ian and I were discussing this yesterday. Could the Haskell Library
Platform *be*
simonpj:
Don, Duncan
| We need to do something about the Haskell library platform around the
| 6.10 release too. At least a list of libraries considered the
| an minimal platform for support by the distros.
Simon and Ian and I were discussing this yesterday. Could the
Haskell Library
duncan.coutts:
On Thu, 2008-06-19 at 11:38 +0100, Simon Marlow wrote:
Neil Mitchell wrote:
While I was away last week I jotted down a list of priorities for 6.10.
Some of these are in the bug tracker and some aren't, but I think it'd
be a good idea for us to first discuss what
On Fri, 2008-06-20 at 06:38 +0100, Simon Peyton-Jones wrote:
| By the way, is everyone OK with increasing the minimum GHC required to
| 6.4.2? Apart from allowing some more of the cruft to be removed, Cabal
| supports building with GHC = 6.4.2, so this would allow us to use Cabal
| to do more
Duncan Coutts wrote:
On Fri, 2008-06-20 at 06:38 +0100, Simon Peyton-Jones wrote:
| By the way, is everyone OK with increasing the minimum GHC required to
| 6.4.2? Apart from allowing some more of the cruft to be removed, Cabal
| supports building with GHC = 6.4.2, so this would allow us to use
On Thu, 2008-06-19 at 11:38 +0100, Simon Marlow wrote:
Neil Mitchell wrote:
While I was away last week I jotted down a list of priorities for 6.10.
Some of these are in the bug tracker and some aren't, but I think it'd be
a good idea for us to first discuss what we really want to see
Hi
Does anyone have any objections to us doing this? I agree it would be a
substantial win. We should consider cabal-install to be a part of Cabal -
indeed the 'cabal' command is the preferred UI for Cabal now, so to ship
one without the other seems wrong.
We'll also have to
On Thu, 2008-06-19 at 12:12 +0100, Neil Mitchell wrote:
Hi
Does anyone have any objections to us doing this? I agree it would be a
substantial win. We should consider cabal-install to be a part of Cabal
-
indeed the 'cabal' command is the preferred UI for Cabal now, so to ship
Neil Mitchell wrote:
Hi
While I was away last week I jotted down a list of priorities for 6.10. Some
of these are in the bug tracker and some aren't, but I think it'd be a good
idea for us to first discuss what we really want to see happen in the 6.10 time
frame and then update the ticket
marlowsd:
Neil Mitchell wrote:
While I was away last week I jotted down a list of priorities for 6.10.
Some of these are in the bug tracker and some aren't, but I think it'd
be a good idea for us to first discuss what we really want to see
happen in the 6.10 time frame
isaacdupree:
Neil Mitchell wrote:
Hi
While I was away last week I jotted down a list of priorities for 6.10.
Some of these are in the bug tracker and some aren't, but I think it'd
be a good idea for us to first discuss what we really want to see
happen in the 6.10 time frame
On Thu, Jun 19, 2008 at 11:38:06AM +0100, Simon Marlow wrote:
Neil Mitchell wrote:
While I was away last week I jotted down a list of priorities for 6.10.
Some of these are in the bug tracker and some aren't, but I think it'd
be a good idea for us to first discuss what we really want
| By the way, is everyone OK with increasing the minimum GHC required to
| 6.4.2? Apart from allowing some more of the cruft to be removed, Cabal
| supports building with GHC = 6.4.2, so this would allow us to use Cabal
| to do more of the building work.
What specifically does 6.4.2 provide that
: Priorities for 6.10
|
| Hi folks,
|
| While I was away last week I jotted down a list of priorities for 6.10. Some
| of these are in the bug tracker and some aren't, but I think it'd be a good
| idea for us to first discuss what we really want to see happen in the 6.10
| time frame and then update
On Mon, Jun 16, 2008 at 12:39:21PM +0100, Simon Marlow wrote:
* Extensible exceptions
* More library reorganisation
#1338 is the ticket for this. It's more-or-less blocked on extensible
exceptions, though.
By the way, is everyone OK with increasing the minimum GHC required to
6.4.2? Apart
On Mon, 2008-06-16 at 12:39 +0100, Simon Marlow wrote:
* Back-end rewrite, remove mangler (see also #1501)
* shared libraries (#1876)
* parallel GC (close #1589, #2185)
* Haddock 2 (see also #1964 (GHC.Prim), #2335 (build problem))
* Unicode encoding/decoding for Text I/O handles.
Hi folks,
While I was away last week I jotted down a list of priorities for 6.10. Some
of these are in the bug tracker and some aren't, but I think it'd be a good
idea for us to first discuss what we really want to see happen in the 6.10 time
frame and then update the ticket database to match
* Put in place a robust solution to the backwards-compatibility problem
Which one is that? Not being able to use one lib with different GHCs,
I fear?-)
Please circulate any additional items you can think of.
One immediately comes to mind from recent discussions:
* initial GHC API
Hi
* initial GHC API improvements: provide generic traversals of GHC
ASTs (via Data/Typeable)
Seconded. A simple Data/Typeable will cover most uses, but it seems
because of the particular data types a Functor/Traversable instance
may be useful.
The other useful thing would be to get the GHC
On Mon, 2008-06-16 at 12:39 +0100, Simon Marlow wrote:
* Back-end rewrite, remove mangler (see also #1501)
* shared libraries (#1876)
* parallel GC (close #1589, #2185)
* Haddock 2 (see also #1964 (GHC.Prim), #2335 (build problem))
* Unicode encoding/decoding for Text I/O handles.
35 matches
Mail list logo
