[mailto:jwl...@gmail.com]
Sent: woensdag 8 oktober 2014 18:22
To: Edward Z. Yang
Cc: ghc-devs@haskell.org; Simon Marlow
Subject: Re: Tentative high-level plans for 7.10.1
Speaking for myself, I don't think the question of doing a 7.8.4 release at all
needs to be entangled with the LTS issue
boun...@haskell.org] on behalf of Thomas
Winant [thomas.win...@cs.kuleuven.be]
Sent: 07 October 2014 17:07
To: ghc-devs@haskell.org
Subject: Re: Tentative high-level plans for 7.10.1
Hi,
On 2014-10-03 23:35, Austin Seipp wrote:
..
Here are the major patches on Phabricator still needing review, t
Speaking for myself, I don't think the question of doing a 7.8.4 release at
all needs to be entangled with the LTS issue.
On Wed, Oct 8, 2014 at 8:23 AM, Edward Z. Yang wrote:
> Excerpts from Herbert Valerio Riedel's message of 2014-10-08 00:59:40
> -0600:
> > However, should GHC 7.8.x turn out
Excerpts from Herbert Valerio Riedel's message of 2014-10-08 00:59:40 -0600:
> However, should GHC 7.8.x turn out to become a LTS-ishly maintained
> branch, we may want to consider converting it to a similiar Git
> structure as GHC HEAD currently is, to avoid having to keep two
> different sets of
[mailto:george.colpi...@gmail.com]
Sent: 08 October 2014 01:35
To: Simon Peyton Jones
Cc: Ben Gamari; Austin Seipp; ghc-devs@haskell.org; Simon Marlow
Subject: Re: Tentative high-level plans for 7.10.1
I agree a section show stoppers is a good idea, in parallel would it make sense
to use the priority
On 2014-10-08 at 02:13:01 +0200, Carter Schonwald wrote:
> the checkout process for the 7.8 branch is a bit involved (and NB: you
> really want to use a different tree than one for working on head, the
> checkout process is different
> )
>
> $ git clone -b ghc-7.8 git://git.haskell.org/ghc.git ghc-
Hello,
On 2014-10-08 at 02:34:50 +0200, George Colpitts wrote:
> I agree a section show stoppers is a good idea, in parallel would it
> make sense to use the priority "highest" for tickets that we consider
> showstoppers?
I think, they are marked 'highest' already
Btw, one could additionally add
> fixes that are harder.
>
> Opinions? I'm not making a ruling here!
>
> Simon
>
> | -Original Message-
> | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Ben
> | Gamari
> | Sent: 04 October 2014 04:52
> | To: Austin Seipp;
or three personal statements up front.)
>>
>> Concerning 7.8.4 itself, I think we could review the decision to abandon
>> it, in the light of new information. We might, for example, fix
>> show-stoppers, include fixes that are easy to apply, and not-include other
>> fix
ts up front.)
>
> Concerning 7.8.4 itself, I think we could review the decision to abandon
> it, in the light of new information. We might, for example, fix
> show-stoppers, include fixes that are easy to apply, and not-include other
> fixes that are harder.
>
> Opinions? I'm n
nclusion is "we don't do this". Again, move to an appendix of
not-implemented ideas.
Try to focus on the actual design.
Thanks!
Simon
From: ghc-devs [ghc-devs-boun...@haskell.org] on behalf of Thomas Winant
[thomas.win...@cs.kuleuven.
To complement what Thomas said: Phabricator currently claims that the
patch is not building, but if I understand Thomas correctly, this is
the consequence of a limitation of the Phabricator builder which is
not treating the haddock part of the patch correctly.
So to reiterate: the partial type sig
Hi,
On 2014-10-03 23:35, Austin Seipp wrote:
..
Here are the major patches on Phabricator still needing review, that I
think we'd like to see for 7.10.1:
- D168: Partial type signatures
..
As Austin said, our patch implementing Partial Type Signatures is still
up for code review on Phabrica
Simon Peyton Jones writes:
> My conclusion
>
> * I think we (collectively!) should make a serious attempt to fix
> show-stopping
>bugs on a major release branch. (I agree that upgrading to the next major
>release often simply brings in a new wave of bugs because of GHC's
>rapid de
First off, I just wanted to tell everyone - thank you for the feedback!
I actually left these tickets in their place/milestones just in case
something like this popped up, so I wouldn't have to undo it later. It
seems like there's actually a fair amount of support for 7.8.4, where
before we didn't
> Our intent has always been that that the latest version on each branch is
> solid. There have been one or two occasions when we have knowingly abandoned
> a dodgy release branch entirely, but not many.
Perhaps we could do the opposite. Announce beforehand that
a release branch X is going to b
I re-targeted some of the bugs that were "obviously" the same SpecConstr
issue to 7.8.4. There are a few others that should probably also be
re-targeted, but I couldn't tell from a quick scan of the long comment
threads.
Looking at the 7.8.4 status page, it's now quite clear that the SpecConstr
bu
On Tue, Oct 7, 2014 at 10:12 AM, Simon Peyton Jones
wrote:
> | 8960 looks rather serious and potentially makes all of 7.8 a no-go
> | for some users.
>
I think this is the big issue. If you look at all the related bugs linked
from #8960, lots of users are affected. I think this bug alone probabl
Subject: Re: Tentative high-level plans for 7.10.1
The steps for making a GHC release are here:
https://ghc.haskell.org/trac/ghc/wiki/MakingReleases
So, for the record, making a release is not *that* arduous, but it
does take time. On average it will take me about 1 day or so to go
from
ri
| Sent: 04 October 2014 04:52
| To: Austin Seipp; ghc-devs@haskell.org
| Cc: Simon Marlow
| Subject: Re: Tentative high-level plans for 7.10.1
|
| Austin Seipp writes:
|
| snip.
|
| >
| > We do not believe we will ship a 7.8.4 at all, contrary to what you
| > may have seen o
Hello,
Note: you actually don't have to backport anything. Leave it for people
how are interested in LTS release.
As haskell enthusiast, I like all the features GHC comes with each
release. But as working haskell programmer I'm tired. All my code I
wrote at work will probably work with ghc-6.8, b
The steps for making a GHC release are here:
https://ghc.haskell.org/trac/ghc/wiki/MakingReleases
So, for the record, making a release is not *that* arduous, but it
does take time. On average it will take me about 1 day or so to go
from absolutely-nothing to release announcement:
1. Bump version
On Mon, Oct 6, 2014 at 5:38 PM, Johan Tibell wrote:
> On Mon, Oct 6, 2014 at 11:28 AM, Herbert Valerio Riedel <
> hvrie...@gmail.com> wrote:
>
>> On 2014-10-06 at 11:03:19 +0200, p.k.f.holzensp...@utwente.nl wrote:
>> > The danger, of course, is that people aren't very enthusiastic about
>> > bug
Hello Daniel,
On Mon, 2014-10-06 at 12:46 +0200, Daniel Trstenjak wrote:
> > So, if 1.4.x, 1.5.x, 1.6.x and 1.7.x are 'supported' versions, and some
> > bug is found in 1.6.2, but turns out to be introduced in 1.5.1, we fix
> > the bug in the 1.5 branch.
> >
> > Then, if the bugfix is important e
On 2014-10-06 at 11:50:03 +0200, Malcolm Wallace wrote:
> On 6 Oct 2014, at 10:28, Herbert Valerio Riedel wrote:
>
>> As I'm not totally sure what you mean: Assuming we already had decided
>> years ago to follow LTS-style, given GHC 7.0, 7.2, 7.4, 7.6, 7.8 and the
>> future 7.10; which of those GHC
Hi Nicolas,
> So, if 1.4.x, 1.5.x, 1.6.x and 1.7.x are 'supported' versions, and some
> bug is found in 1.6.2, but turns out to be introduced in 1.5.1, we fix
> the bug in the 1.5 branch.
>
> Then, if the bugfix is important enough, we merge 1.4 in 1.5 (which can
> be a no-op), 1.5 in 1.6, and 1
On Mon, 2014-10-06 at 11:38 +0200, Johan Tibell wrote:
> On Mon, Oct 6, 2014 at 11:28 AM, Herbert Valerio Riedel
> wrote:
>
> > On 2014-10-06 at 11:03:19 +0200, p.k.f.holzensp...@utwente.nl wrote:
> > > The danger, of course, is that people aren't very enthusiastic about
> > > bug-fixing older ve
On 6 Oct 2014, at 10:28, Herbert Valerio Riedel wrote:
> As I'm not totally sure what you mean: Assuming we already had decided
> years ago to follow LTS-style, given GHC 7.0, 7.2, 7.4, 7.6, 7.8 and the
> future 7.10; which of those GHC versions would you have been considered
> a LTS version?
W
On Mon, Oct 6, 2014 at 11:28 AM, Herbert Valerio Riedel
wrote:
> On 2014-10-06 at 11:03:19 +0200, p.k.f.holzensp...@utwente.nl wrote:
> > The danger, of course, is that people aren't very enthusiastic about
> > bug-fixing older versions of a compiler, but for
> > language/compiler-uptake, this mi
On 2014-10-06 at 11:03:19 +0200, p.k.f.holzensp...@utwente.nl wrote:
[...]
> The idea behind an LTS-GHC would be to continue bug-fixing on the
> LTS-version, even if newer major versions no longer get bug-fixing
> support. To some extent, there will be redundancies (bugs that have
> disappeared i
> Here are the major patches on Phabricator still needing review, that I
> think we'd like to see for 7.10.1:
>
>- D72: New rebindable syntax for arrows.
I don't think D72 will make it in. I started to work on this a couple of months
ago but the work
has stalled. I just don't understand arrow
c: Simon Marlow; ghc-devs@haskell.org
Subject: Re: Tentative high-level plans for 7.10.1
Speaking as a user, I think Johan's concern is well-founded. For us, ghc-7.8.3
was the first of the 7.8 line that was really usable in production, due to
#8960 and other bugs. Sure, that can be worked arou
Speaking as a user, I think Johan's concern is well-founded. For us,
ghc-7.8.3 was the first of the 7.8 line that was really usable in
production, due to #8960 and other bugs. Sure, that can be worked around
in user code, but it takes some time for developers to locate the issues,
track down the
On Fri, Oct 3, 2014 at 11:35 PM, Austin Seipp wrote:
> - Cull and probably remove the 7.8.4 milestone.
>- Simply not enough time to address almost any of the tickets
> in any reasonable timeframe before 7.10.1, while also shipping them.
>- Only one, probably workarouadble, not game-
Austin Seipp writes:
snip.
>
> We do not believe we will ship a 7.8.4 at all, contrary to what you
> may have seen on Trac - we never decided definitively, but there is
> likely not enough time. Over the next few days, I will remove the
> defunct 7.8.4 milestone, and re-triage the assigned ticke
Hi *,
Today, Mikolaj and I discussed and plotted out a quick, high-level
roadmap for the 7.10.1 release, based on our earlier plans. Consider
this the 10,000 foot view (the last one was like a view from space).
**The TL;DR** - We think the freeze and branching for major things
will happen in _5 t
36 matches
Mail list logo
