Some people had asked what the users want and about typical usage, so I'll
give the my perspective. I consider myself a pretty typical user of
Haskell: PhD student (in theory, not languages), but still pushing the
boundaries of the compiler. I've filed quite a few bugs, so I have
experience with ha
On 09/07/2015 04:57 PM, Simon Peyton Jones wrote:
> Merging and releasing a fix to the stable branch always carries a cost:
> it might break something else. There is a real cost to merging, which
> is why we've followed the lazy strategy that Ben describes.
>
A valid point, but the upside is tha
: GHC developers
| Subject: Re: more releases
|
| Richard Eisenberg writes:
|
| > I think some of my idea was misunderstood here: my goal was to have
| > quick releases only from the stable branch. The goal would not be to
| > release the new and shiny, but instead to get bugfixe
having a large number of versions of GHC out there can make it difficult
for library authors, package curators, and large open source projects, due
to variety of what people are using.
For point releases, if we do it right, this *should* not happen, since the
changes *should* be backwards-compa
I have the impression (no data to back it up, though) that no small number
of users download bindists (because most OS packages are out of date:
Debian Unstable is still on 7.8.4, as is Ubuntu Wily; Arch is on 7.10.1).
On Wed, Sep 2, 2015 at 12:04 PM, Ben Gamari wrote:
> Richard Eisenberg write
Richard Eisenberg writes:
> I think some of my idea was misunderstood here: my goal was to have
> quick releases only from the stable branch. The goal would not be to
> release the new and shiny, but instead to get bugfixes out to users
> quicker. The new and shiny (master) would remain as it is
I think some of my idea was misunderstood here: my goal was to have quick
releases only from the stable branch. The goal would not be to release the new
and shiny, but instead to get bugfixes out to users quicker. The new and shiny
(master) would remain as it is now. In other words: more users w
On 2015-09-02 at 12:43:57 +0200, Ben Gamari wrote:
[...]
> The question is whether users want more rapid releases. Those working on
> GHC will use their own builds. Most users want something reasonably
> stable (in both the interface sense and the reliability sense) and
> therefore I suspect woul
Richard Eisenberg writes:
> On Sep 1, 2015, at 12:01 AM, Herbert Valerio Riedel
> wrote:
>
>> I'd say mostly organisational overhead which can't be fully automated
>> (afaik, Ben has already automated large parts but not everything can be):
>>
>> - Coordinating with people creating and testing
On Sep 1, 2015, at 12:01 AM, Herbert Valerio Riedel wrote:
> I'd say mostly organisational overhead which can't be fully automated
> (afaik, Ben has already automated large parts but not everything can be):
>
> - Coordinating with people creating and testing the bindists
This was the sort of t
On 2015-09-01 at 08:45:40 +0200, Richard Eisenberg wrote:
> An interesting topic came up over dinner tonight: what if GHC made
> more releases? As an extreme example, we could release a new point
> version every time a bug fix gets merged to the stable branch. This
> may be a terrib
d Eisenberg wrote:
> Hi devs,
>
> An interesting topic came up over dinner tonight: what if GHC made more
> releases? As an extreme example, we could release a new point version every
> time a bug fix gets merged to the stable branch. This may be a terrible
> idea. But what&#
Hi devs,
An interesting topic came up over dinner tonight: what if GHC made more
releases? As an extreme example, we could release a new point version every
time a bug fix gets merged to the stable branch. This may be a terrible idea.
But what's stopping us from doing so?
The bi
13 matches
Mail list logo
