Tentative high-level plans for 7.10.1

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
36 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Tentative high-level plans for 7.10.1

Austin Seipp-5
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 to 6 weeks from now_, in early/mid November. The
release will happen in Feburary. Developers, please read some code
(see below), and get your stuff in! The initial bug list will come
next week for you to look at.

---------------------------

The not-quite-TL;DR version:

We'll get about 4 months of fixes into STABLE. This stability period
will come at a typically low-point during the year, when many people
will be preoccupied with Holidays. So, we're trying to aim far ahead,
and try to give STABLE a long, official 'cooking period'.

Feature inclusions after the freeze _are_ negotiable, but not large
changes. Expect us to say "No" more often this time around. The STABLE
branch will only be touchable by me and Herbert.

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 tickets.

We don't have any expected time for an RC just yet.

I will spend the next few days culling the 7.10.1 milestone to contain
appropriate tickets. Expect a list of these tickets early next week,
with more info.

Developers: if you have time, **please** review some code, and get
your stuff in too! Petition people to review things of yours. Review
things other people wrote, and learn new stuff. High five each other
afterwords.

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
   - D72: New rebindable syntax for arrows.
   - D155: LLVM 3.5 compatibility
   - D169: Source code note infrastructure
   - D202: Injective type families
   - Edward Yang's HEAP_ALLOCED saga, D270 through D293
   - D130: Implementation of hsig (module signatures)

It is possible not all of these will make it. But I think they're
solid priorities to try and land soon. Please let me know if you
disagree with this.

After I publish the bug list, please also take a look, and use your
judgement to include or remove things you think are sensible for
7.10.1 (I trust your judgement, and we can always talk it out later).

I think that's all. Here's a full roadmap below from our notes:

-----------------------------------

 - Expected ETA for 7.10.1:
   - Roughly Feburary 2015.
   - Expected code freeze ~5wks
     - Entails making the stable branch
     - Tentatively create branch on Nov. 7th.
     - ~3-4mo's of freeze time for STABLE.
     - Empirically a low-point in development due to Holidays, but
gives us a lot of time.

 - 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-changing
     bug (#9303) marked for 7.8.4.
   - No particular pressure on any outstanding bugs to release immediately.
   - ANY release would be extremely unlikely, but if so, only
     backed by the most critical of bugs.
   - We will move everything in 7.8.4 milestone to 7.10.1 milestone.
     - To accurately catalogue what was fixed.
     - To eliminate confusion.

 - Cull the 7.10.1 milestone
   - Currently ~700 tickets.
   - 31 high tickets.
   - 1 highest priority ticket.
   - Bulk of them will need moved out to 7.12.1.
     - Ask developers/users to move things back in.
     - Demote any old tickets out of highest according to bug tracker policy.
     - Alert people these are our priorities.

 - Go through ONLY high/highest priority tickets for 7.10.1.
   - Email ghc-devs with plans.

 - Major tentative patches for 7.10
   - D168: Partial type signatures
   - D72: New rebindable syntax for arrows.
   - D155: LLVM 3.5 compatibility (not big, but important for users!)
   - D169: Source code note infrastructure (partially reviewed, Austin
to review)
   - D202: Injective type families
   - Edward Yang's HEAP_ALLOCED saga, D270 through D293
   - D130: Implementation of hsig (module signatures)

--
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

Reply | Threaded
Open this post in threaded view
|

Tentative high-level plans for 7.10.1

Ben Gamari
Austin Seipp <austin at well-typed.com> 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 tickets.
>
The only potential issue here is that not a single 7.8 release will be
able to bootstrap LLVM-only targets due to #9439. I'm not sure how much
of an issue this will be in practice but there should probably be some
discussion with packagers to ensure that 7.8 is skipped on affected
platforms lest users be stuck with no functional stage 0 compiler.

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141003/5f1026d3/attachment-0001.sig>

Reply | Threaded
Open this post in threaded view
|

Tentative high-level plans for 7.10.1

Johan Tibell-2
In reply to this post by Austin Seipp-5
On Fri, Oct 3, 2014 at 11:35 PM, Austin Seipp <austin at well-typed.com> 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-changing
>      bug (#9303) marked for 7.8.4.
>    - No particular pressure on any outstanding bugs to release immediately.
>    - ANY release would be extremely unlikely, but if so, only
>      backed by the most critical of bugs.
>    - We will move everything in 7.8.4 milestone to 7.10.1 milestone.
>      - To accurately catalogue what was fixed.
>      - To eliminate confusion.
>

#8960 looks rather serious and potentially makes all of 7.8 a no-go for
some users. I'm worried that we're (in general) pushing too many bug fixes
towards future major versions. Since major versions tend to add new bugs,
we risk getting into a situation where no major release is really solid.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141004/12503687/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Tentative high-level plans for 7.10.1

John Lato-2
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 bug, and implement the workaround.  And even 7.8.3 has some
bugs that cause minor annoyances (either ugly workarounds or intermittent
build failures that I haven't had the time to debug); it's definitely not
solid.  Similarly, 7.6.3 was the first 7.6 release that we were able to use
in production.  I'm particularly concerned about ghc-7.10 as the AMP means
there will be significant lag in identifying new bugs (since it'll take
time to update codebases for that major change).

For the curious, within the past few days we've seen all the following,
some multiple times, all so far intermittent:

> ghc: panic! (the 'impossible' happened)
> (GHC version 7.8.3.0 for x86_64-unknown-linux):
>     kindFunResult ghc-prim:GHC.Prim.*{(w) tc 34d}

> ByteCodeLink.lookupCE
> During interactive linking, GHCi couldn't find the following symbol:
>     some_mangled_name_closure

> ghc: mmap 0 bytes at (nil): Invalid Argument

> internal error: scavenge_one: strange object 2022017865

Some of these I've mapped to likely ghc issues, and some are fixed in HEAD,
but so far I haven't had an opportunity to put together reproducible test
cases.  And that's just bugs that we haven't triaged yet, there are several
more for which workarounds are in place.

John L.

On Sat, Oct 4, 2014 at 2:54 PM, Johan Tibell <johan.tibell at gmail.com> wrote:

> On Fri, Oct 3, 2014 at 11:35 PM, Austin Seipp <austin at well-typed.com>
> 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-changing
>>      bug (#9303) marked for 7.8.4.
>>    - No particular pressure on any outstanding bugs to release
>> immediately.
>>    - ANY release would be extremely unlikely, but if so, only
>>      backed by the most critical of bugs.
>>    - We will move everything in 7.8.4 milestone to 7.10.1 milestone.
>>      - To accurately catalogue what was fixed.
>>      - To eliminate confusion.
>>
>
> #8960 looks rather serious and potentially makes all of 7.8 a no-go for
> some users. I'm worried that we're (in general) pushing too many bug fixes
> towards future major versions. Since major versions tend to add new bugs,
> we risk getting into a situation where no major release is really solid.
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141006/245836fb/attachment-0001.html>

Reply | Threaded
Open this post in threaded view
|

Tentative high-level plans for 7.10.1

p.k.f.holzenspies@utwente.nl
I don't know whether this has ever been considered as an idea, but what about having a notion of Long Term Support version (similar to how a lot of processor and operating systems vendors go about this).


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 in newer versions because newer code does the same and more, still needing to be fixed on the LTS code base), but the upside would be a clear prioritisation between stability (LTS) and innovation (latest major release).


The current policy for feature *use* in the GHC code-base is that they're supported in (at least) three earlier major release versions. Should we go the LTS-route, the logical choice would be to demand the latest LTS-version. 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 might actually be a Better Way.


Thoughts?


Ph.





________________________________
From: John Lato <jwlato at gmail.com>
Sent: 06 October 2014 01:10
To: Johan Tibell
Cc: Simon Marlow; ghc-devs at 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 around in user code, but it takes some time for developers to locate the issues, track down the bug, and implement the workaround.  And even 7.8.3 has some bugs that cause minor annoyances (either ugly workarounds or intermittent build failures that I haven't had the time to debug); it's definitely not solid.  Similarly, 7.6.3 was the first 7.6 release that we were able to use in production.  I'm particularly concerned about ghc-7.10 as the AMP means there will be significant lag in identifying new bugs (since it'll take time to update codebases for that major change).

For the curious, within the past few days we've seen all the following, some multiple times, all so far intermittent:

> ghc: panic! (the 'impossible' happened)
> (GHC version 7.8.3.0 for x86_64-unknown-linux):
>     kindFunResult ghc-prim:GHC.Prim.*{(w) tc 34d}

> ByteCodeLink.lookupCE
> During interactive linking, GHCi couldn't find the following symbol:
>     some_mangled_name_closure

> ghc: mmap 0 bytes at (nil): Invalid Argument

> internal error: scavenge_one: strange object 2022017865

Some of these I've mapped to likely ghc issues, and some are fixed in HEAD, but so far I haven't had an opportunity to put together reproducible test cases.  And that's just bugs that we haven't triaged yet, there are several more for which workarounds are in place.

John L.

On Sat, Oct 4, 2014 at 2:54 PM, Johan Tibell <johan.tibell at gmail.com<mailto:johan.tibell at gmail.com>> wrote:
On Fri, Oct 3, 2014 at 11:35 PM, Austin Seipp <austin at well-typed.com<mailto:austin at well-typed.com>> 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-changing
     bug (#9303) marked for 7.8.4.
   - No particular pressure on any outstanding bugs to release immediately.
   - ANY release would be extremely unlikely, but if so, only
     backed by the most critical of bugs.
   - We will move everything in 7.8.4 milestone to 7.10.1 milestone.
     - To accurately catalogue what was fixed.
     - To eliminate confusion.

#8960 looks rather serious and potentially makes all of 7.8 a no-go for some users. I'm worried that we're (in general) pushing too many bug fixes towards future major versions. Since major versions tend to add new bugs, we risk getting into a situation where no major release is really solid.


_______________________________________________
ghc-devs mailing list
ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
http://www.haskell.org/mailman/listinfo/ghc-devs


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141006/b9e31359/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Tentative high-level plans for 7.10.1

Jan Stolarek
In reply to this post by Austin Seipp-5
> 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 arrows well enough :-/ Sophie Taylor (aka spacekitteh)
expressed some interest in this and we chatted a bit about it on IRC. But I haven't heard
anything from Sophie in the past 2 weeks so I don't know whether she intends to pick up my work
or not.

Janek

Reply | Threaded
Open this post in threaded view
|

Tentative high-level plans for 7.10.1

Herbert Valerio Riedel-3
In reply to this post by p.k.f.holzenspies@utwente.nl
On 2014-10-06 at 11:03:19 +0200, p.k.f.holzenspies at 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 in newer versions because newer code does the same and
> more, still needing to be fixed on the LTS code base), but the upside
> would be a clear prioritisation between stability (LTS) and innovation
> (latest major release).

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?

[...]

> 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 might actually be a Better Way.

Maybe some of the commercial GHC users might be interested in donating
the manpower to maintain older GHC versions. It's mostly a
time-consuming QA & auditing process to maintain old GHCs.

Reply | Threaded
Open this post in threaded view
|

Tentative high-level plans for 7.10.1

Johan Tibell-2
On Mon, Oct 6, 2014 at 11:28 AM, Herbert Valerio Riedel <hvriedel at gmail.com>
wrote:

> On 2014-10-06 at 11:03:19 +0200, p.k.f.holzenspies at 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 might actually be a Better Way.
>
> Maybe some of the commercial GHC users might be interested in donating
> the manpower to maintain older GHC versions. It's mostly a
> time-consuming QA & auditing process to maintain old GHCs.
>

What can we do to make that process cheaper? In particular, which are the
manual steps in making a new GHC release today?

In the long run back porting bugfixes is the route successful OSS projects
take. Once people have written large enough Haskell programs they will stop
jumping onto the newer version all the time and will demand backports of
bug fixes. This is already happening to some extent in cabal (as cabal is
tied to a ghc release which means we need to backport changes sometimes.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141006/47356e5a/attachment-0001.html>

Reply | Threaded
Open this post in threaded view
|

Tentative high-level plans for 7.10.1

Malcolm Wallace-2
In reply to this post by Herbert Valerio Riedel-3

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?


We continue to use 7.2, at least partly because all newer versions of ghc have had significant bugs that affect us.  In fact, 7.2.2 also has a show-stopping bug, but we patched it ourselves to create our very own custom ghc-7.2.3 distribution.

Regards,
    Malcolm

Reply | Threaded
Open this post in threaded view
|

Tentative high-level plans for 7.10.1

Nicolas Trangez
In reply to this post by Johan Tibell-2
On Mon, 2014-10-06 at 11:38 +0200, Johan Tibell wrote:

> On Mon, Oct 6, 2014 at 11:28 AM, Herbert Valerio Riedel <hvriedel at gmail.com>
> wrote:
>
> > On 2014-10-06 at 11:03:19 +0200, p.k.f.holzenspies at 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 might actually be a Better Way.
> >
> > Maybe some of the commercial GHC users might be interested in donating
> > the manpower to maintain older GHC versions. It's mostly a
> > time-consuming QA & auditing process to maintain old GHCs.
> >
>
> What can we do to make that process cheaper? In particular, which are the
> manual steps in making a new GHC release today?
>
> In the long run back porting bugfixes is the route successful OSS projects
> take. Once people have written large enough Haskell programs they will stop
> jumping onto the newer version all the time and will demand backports of
> bug fixes. This is already happening to some extent in cabal (as cabal is
> tied to a ghc release which means we need to backport changes sometimes.)

Quick note/experience report:

In my experience maintaining a project which has several older/supported
'production' versions, using backports is counter-productive, and we
decided to manage things the other way around (which is fairly easy to
do thanks to git and git-imerge):

Instead of fixing things in the latest version of the product, we fix
things in the *oldest* version of the product which should contain the
fix (or feature, whatever). Then we regularly forward-merge version
branches into the next version (especially when a release is made).

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.6 into 1.7. As such, every version branch
'contains' all 'older' branches.

Even though the codebase can diverge quite a bit between the 1.5 and 1.7
tree, these merges tend to be fairly easy, especially since the required
changes are split between the 1.5-1.6 merge and the 1.6-1.7 merge.

'Small' commits with clear purpose, minimal changes & clear commit
messages tend to help a lot in this process as well (especially when
using git-imerge). The squashing performed by Phab as mentioned in some
other messages on the list can be troublesome in this regard... (I'm not
a big fan of squash merges myself, from a maintainer POV).

Nicolas


Reply | Threaded
Open this post in threaded view
|

Tentative high-level plans for 7.10.1

Daniel Trstenjak-2

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.6 into 1.7. As such, every version branch
> 'contains' all 'older' branches.

I don't like this practise, because you certainly don't want to always
incorprocate all commits of one release branch into an other.

Just think about a hackish bug fix needed to be added in a former
release, and in a newer release the problem has been solved in a
completely different way, and now, if you have bad luck, the former
release branch merges without conflicts into the new one, now getting
the hackish fix into the new release, which might be even harmful.

IMHO using cherry picking in this case is a lot better manageable.


Greetings,
Daniel

Reply | Threaded
Open this post in threaded view
|

Tentative high-level plans for 7.10.1

Herbert Valerio Riedel-3
In reply to this post by Malcolm Wallace-2
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 versions would you have been considered
>> a LTS version?
>
>
> We continue to use 7.2, at least partly because all newer versions of
> ghc have had significant bugs that affect us.  In fact, 7.2.2 also has
> a show-stopping bug, but we patched it ourselves to create our very
> own custom ghc-7.2.3 distribution.

I'd like to point out that's kinda ironic, as of *all* the GHC releases,
you had to stay on the one major release that was considered a
non-proper tech-preview... :-)

Cheers,
  hvr

Reply | Threaded
Open this post in threaded view
|

Tentative high-level plans for 7.10.1

Nicolas Trangez
In reply to this post by Daniel Trstenjak-2
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 enough, we merge 1.4 in 1.5 (which can
> > be a no-op), 1.5 in 1.6, and 1.6 into 1.7. As such, every version branch
> > 'contains' all 'older' branches.
>
> I don't like this practise, because you certainly don't want to always
> incorprocate all commits of one release branch into an other.
>
> Just think about a hackish bug fix needed to be added in a former
> release, and in a newer release the problem has been solved in a
> completely different way, and now, if you have bad luck, the former
> release branch merges without conflicts into the new one, now getting
> the hackish fix into the new release, which might be even harmful.

Agree, although I think this is less of an issue in practice because we
enforce code reviews for all commits, including 'merge' commits, even if
the merge was 100% automatic (hence we have PRs for '1.5-for-1.6'
branches once in a while). These 'workarounds' are spotted easily during
this process.

Next to that, chances are fairly low a 'hack' won't in any way conflict
with a 'proper fix', since they tend to touch (a portion of) the same
code most of the time (except in build systems maybe). Using
'git-imerge' helps here quite a bit as well, since the conflicts aren't
buried between 100s of unrelated changes (like what git-merge does).

> IMHO using cherry picking in this case is a lot better manageable.

Yet it has a (IMHO) major drawback: it requires a system next to VCS
(issue tracker or alike) to make sure all fixes are propagated to all
applicable versions, which all too often results in (human) error. "Hey,
we reported this against 1.6.3, and it was fixed in 1.6.4, but now we
upgraded to 1.7.3 which was released after 1.6.4 and the bug is back" is
no good PR.

Anyway, it's not like I intend to push GHC development/maintenance in
any specific direction at all, just wanted to provide some experience
report :-)

Regards,

Nicolas


Reply | Threaded
Open this post in threaded view
|

Tentative high-level plans for 7.10.1

John Lato-2
In reply to this post by Johan Tibell-2
On Mon, Oct 6, 2014 at 5:38 PM, Johan Tibell <johan.tibell at gmail.com> wrote:

> On Mon, Oct 6, 2014 at 11:28 AM, Herbert Valerio Riedel <
> hvriedel at gmail.com> wrote:
>
>> On 2014-10-06 at 11:03:19 +0200, p.k.f.holzenspies at 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 might actually be a Better Way.
>>
>> Maybe some of the commercial GHC users might be interested in donating
>> the manpower to maintain older GHC versions. It's mostly a
>> time-consuming QA & auditing process to maintain old GHCs.
>>
>
> What can we do to make that process cheaper? In particular, which are the
> manual steps in making a new GHC release today?
>

I would very much like to know this as well.  For ghc-7.8.3 there were a
number of people volunteering manpower to finish up the release, but to the
best of my knowledge those offers weren't taken up, which makes me think
that the extra overhead for coordinating more people would outweigh any
gains.  From the outside, it appears that the process/workflow could use
some improvement, perhaps in ways that would make it simpler to divide up
the workload.

John L.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141007/59bccff6/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Tentative high-level plans for 7.10.1

Austin Seipp-5
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, update configure.ac, tag.
 2. Build source tarball (this requires 1 build, but can be done very quickly).
 3. Make N binary builds for each platform (the most time consuming
part, as this requires heavy optimizations in the builds).
 4. Upload documentation for all libraries.
 5. Update webpage and upload binaries.
 6. Send announcement.
 7. Upload binaries from other systems later.

Herbert has graciously begun taking care of stewarding and uploading
the libraries. So, there are a few steps we could introduce to
alleviate this process technically in a few ways, but ultimately all
of these have to happen, pretty much (regardless of the automation
involved).

But I don't think this is the real problem.

The real problem is that GHC moves forward in terms of implementation
extremely, extremely quickly. It is not clear how to reconcile this
development pace with something like needing dozens of LTS releases
for a stable version. At least, not without a lot of concentrated
effort from almost every single developer. A lot of it can be
alleviated through social process perhaps, but it's not strictly
technical IMO.

What do I mean by that? I mean that:

 - We may introduce a feature in GHC version X.Y
 - That might have a bug, or other problems.
 - We may fix it, and in the process, fix up a few other things and
refactor HEAD, which will be GHC X.Y+2 eventually.
 - Repeat steps 2-3 a few times.
 - Now we want to backport the fixes for that feature in HEAD back to X.Y.
 - But GHC X.Y has *significantly* diverged from HEAD in that
timeframe, because of step 3 being repeated!

In other words: we are often so aggressive at refactoring code that
the *act* of backporting in and of itself can be complicated, and it
gets harder as time goes on - because often the GHC of a year ago is
so much different than the GHC of today.

As a concrete example of this, let's look at the changes between GHC
7.8.2 and GHC 7.8.3:

https://github.com/ghc/ghc/compare/ghc-7.8.2-release...ghc-7.8.3-release

There are about ~110 commits between 7.8.2 and 7.8.3. But as the 7.8
branch lived on, backporting fixes became significantly more complex.
In fact, I estimate close to 30 of those commits were NOT direct 7.8
requirements - but they were brought in because _actual fixes_ were
dependent on them, in non-trivial ways.

Take for example f895f33 by Simon PJ, which fixes #9023. The problem
with f895f33 is that by the time we fixed the bug in HEAD with that
commit, the history had changed significantly from the branch. In
order to get f895f33 to plant easily, I had to backport *at least* 12
to 15 other commits, which it was dependent upon, and commits those
commits were dependent upon, etc etc. I did not see any non-trivial
way to do this otherwise.

I believe at one point Gergo backported some of his fixes to 7.8,
which had since become 'non applicable' (and I thank him for that
greatly), but inevitably we instead brought along the few extra
changes anyway, since they were *still* needed for other fixes. And
some of them had API changes. So the choice was to rewrite 4 patches
for an old codebase completely (the work being done by two separate
people) or backport a few extra patches.

The above is obviously an extreme case. But it stands to reason this
would _only happen again_ with 7.8.4, probably even worse since more
months of development have gone by.

An LTS release would mandate things like no-API-changes-at-all, but
this significantly limits our ability to *actually* backport patches
sometimes, like the above, due to dependent changes. The alternative,
obviously, is to do what Gergo did and manually re-write such a fix
for the older branch. But that means we would have had to do that for
*every patch* in the same boat, including 2 or 3 other fixes we
needed!

Furthermore, while I am a release manager and do think I know a bit
about GHC, it is hopeless to expect me to know it all. I will
absolutely require coordinated effort to help develop 'retropatches'
that don't break API compatibility, from active developers who are
involved in their respective features. And they are almost all
volunteers! Simon and I are the only ones who wouldn't qualify on
that.

So - at what point does it stop becoming 'backporting fixes to older
versions' and instead become literally "working on the older version
of the compiler AND the new one in tandem"? Given our rate of churn
and change internally, this seems like it would be a significant
burden in general to ask of developers. If we had an LTS release of
GHC that lasted 3 years for example, that would mean developers are
expected to work on the current code of their own, *and their old code
for the next three years*. That is an absolutely, undeniably a _huge_
investment to ask of someone. It's not clear how many can actually
hold it (and I don't blame them).

This email is already a bit long (which is extremely unusual for my
emails, I'm sure you all know), but I just wanted to give some insight
on the process.

I think the technical/automation aspects are the easy part. We could
probably fully automate the GHC release process in days, if one or two
people worked on it dilligently. The hard part is actually balancing
the needs and time of users and developers, which is a complex
relationship.

On Mon, Oct 6, 2014 at 6:22 PM, John Lato <jwlato at gmail.com> wrote:

> On Mon, Oct 6, 2014 at 5:38 PM, Johan Tibell <johan.tibell at gmail.com> wrote:
>>
>> On Mon, Oct 6, 2014 at 11:28 AM, Herbert Valerio Riedel
>> <hvriedel at gmail.com> wrote:
>>>
>>> On 2014-10-06 at 11:03:19 +0200, p.k.f.holzenspies at 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 might actually be a Better Way.
>>>
>>> Maybe some of the commercial GHC users might be interested in donating
>>> the manpower to maintain older GHC versions. It's mostly a
>>> time-consuming QA & auditing process to maintain old GHCs.
>>
>>
>> What can we do to make that process cheaper? In particular, which are the
>> manual steps in making a new GHC release today?
>
>
> I would very much like to know this as well.  For ghc-7.8.3 there were a
> number of people volunteering manpower to finish up the release, but to the
> best of my knowledge those offers weren't taken up, which makes me think
> that the extra overhead for coordinating more people would outweigh any
> gains.  From the outside, it appears that the process/workflow could use
> some improvement, perhaps in ways that would make it simpler to divide up
> the workload.
>
> John L.
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>



--
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

Reply | Threaded
Open this post in threaded view
|

Tentative high-level plans for 7.10.1

Yuras Shumovich
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, but I have to switch to
newer ghc twice a year. (The last time it was because gcc/clang issue on
mac os)

LTS release means you MAY backport fixes. If you want or have time, if
there are people interested in that, etc.
Probably we'll have more chances that hackage libraries will support LTS
releases longer then they support regular releases now. As a result it
will be easer to introduce breaking changes like AMP or
Traversable/Foldable proposal.

Thanks,
Yuras

On Mon, 2014-10-06 at 19:45 -0500, Austin Seipp wrote:

> 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, update configure.ac, tag.
>  2. Build source tarball (this requires 1 build, but can be done very quickly).
>  3. Make N binary builds for each platform (the most time consuming
> part, as this requires heavy optimizations in the builds).
>  4. Upload documentation for all libraries.
>  5. Update webpage and upload binaries.
>  6. Send announcement.
>  7. Upload binaries from other systems later.
>
> Herbert has graciously begun taking care of stewarding and uploading
> the libraries. So, there are a few steps we could introduce to
> alleviate this process technically in a few ways, but ultimately all
> of these have to happen, pretty much (regardless of the automation
> involved).
>
> But I don't think this is the real problem.
>
> The real problem is that GHC moves forward in terms of implementation
> extremely, extremely quickly. It is not clear how to reconcile this
> development pace with something like needing dozens of LTS releases
> for a stable version. At least, not without a lot of concentrated
> effort from almost every single developer. A lot of it can be
> alleviated through social process perhaps, but it's not strictly
> technical IMO.
>
> What do I mean by that? I mean that:
>
>  - We may introduce a feature in GHC version X.Y
>  - That might have a bug, or other problems.
>  - We may fix it, and in the process, fix up a few other things and
> refactor HEAD, which will be GHC X.Y+2 eventually.
>  - Repeat steps 2-3 a few times.
>  - Now we want to backport the fixes for that feature in HEAD back to X.Y.
>  - But GHC X.Y has *significantly* diverged from HEAD in that
> timeframe, because of step 3 being repeated!
>
> In other words: we are often so aggressive at refactoring code that
> the *act* of backporting in and of itself can be complicated, and it
> gets harder as time goes on - because often the GHC of a year ago is
> so much different than the GHC of today.
>
> As a concrete example of this, let's look at the changes between GHC
> 7.8.2 and GHC 7.8.3:
>
> https://github.com/ghc/ghc/compare/ghc-7.8.2-release...ghc-7.8.3-release
>
> There are about ~110 commits between 7.8.2 and 7.8.3. But as the 7.8
> branch lived on, backporting fixes became significantly more complex.
> In fact, I estimate close to 30 of those commits were NOT direct 7.8
> requirements - but they were brought in because _actual fixes_ were
> dependent on them, in non-trivial ways.
>
> Take for example f895f33 by Simon PJ, which fixes #9023. The problem
> with f895f33 is that by the time we fixed the bug in HEAD with that
> commit, the history had changed significantly from the branch. In
> order to get f895f33 to plant easily, I had to backport *at least* 12
> to 15 other commits, which it was dependent upon, and commits those
> commits were dependent upon, etc etc. I did not see any non-trivial
> way to do this otherwise.
>
> I believe at one point Gergo backported some of his fixes to 7.8,
> which had since become 'non applicable' (and I thank him for that
> greatly), but inevitably we instead brought along the few extra
> changes anyway, since they were *still* needed for other fixes. And
> some of them had API changes. So the choice was to rewrite 4 patches
> for an old codebase completely (the work being done by two separate
> people) or backport a few extra patches.
>
> The above is obviously an extreme case. But it stands to reason this
> would _only happen again_ with 7.8.4, probably even worse since more
> months of development have gone by.
>
> An LTS release would mandate things like no-API-changes-at-all, but
> this significantly limits our ability to *actually* backport patches
> sometimes, like the above, due to dependent changes. The alternative,
> obviously, is to do what Gergo did and manually re-write such a fix
> for the older branch. But that means we would have had to do that for
> *every patch* in the same boat, including 2 or 3 other fixes we
> needed!
>
> Furthermore, while I am a release manager and do think I know a bit
> about GHC, it is hopeless to expect me to know it all. I will
> absolutely require coordinated effort to help develop 'retropatches'
> that don't break API compatibility, from active developers who are
> involved in their respective features. And they are almost all
> volunteers! Simon and I are the only ones who wouldn't qualify on
> that.
>
> So - at what point does it stop becoming 'backporting fixes to older
> versions' and instead become literally "working on the older version
> of the compiler AND the new one in tandem"? Given our rate of churn
> and change internally, this seems like it would be a significant
> burden in general to ask of developers. If we had an LTS release of
> GHC that lasted 3 years for example, that would mean developers are
> expected to work on the current code of their own, *and their old code
> for the next three years*. That is an absolutely, undeniably a _huge_
> investment to ask of someone. It's not clear how many can actually
> hold it (and I don't blame them).
>
> This email is already a bit long (which is extremely unusual for my
> emails, I'm sure you all know), but I just wanted to give some insight
> on the process.
>
> I think the technical/automation aspects are the easy part. We could
> probably fully automate the GHC release process in days, if one or two
> people worked on it dilligently. The hard part is actually balancing
> the needs and time of users and developers, which is a complex
> relationship.
>
> On Mon, Oct 6, 2014 at 6:22 PM, John Lato <jwlato at gmail.com> wrote:
> > On Mon, Oct 6, 2014 at 5:38 PM, Johan Tibell <johan.tibell at gmail.com> wrote:
> >>
> >> On Mon, Oct 6, 2014 at 11:28 AM, Herbert Valerio Riedel
> >> <hvriedel at gmail.com> wrote:
> >>>
> >>> On 2014-10-06 at 11:03:19 +0200, p.k.f.holzenspies at 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 might actually be a Better Way.
> >>>
> >>> Maybe some of the commercial GHC users might be interested in donating
> >>> the manpower to maintain older GHC versions. It's mostly a
> >>> time-consuming QA & auditing process to maintain old GHCs.
> >>
> >>
> >> What can we do to make that process cheaper? In particular, which are the
> >> manual steps in making a new GHC release today?
> >
> >
> > I would very much like to know this as well.  For ghc-7.8.3 there were a
> > number of people volunteering manpower to finish up the release, but to the
> > best of my knowledge those offers weren't taken up, which makes me think
> > that the extra overhead for coordinating more people would outweigh any
> > gains.  From the outside, it appears that the process/workflow could use
> > some improvement, perhaps in ways that would make it simpler to divide up
> > the workload.
> >
> > John L.
> >
> >
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://www.haskell.org/mailman/listinfo/ghc-devs
> >
>
>
>



Reply | Threaded
Open this post in threaded view
|

Tentative high-level plans for 7.10.1

Simon Peyton Jones
In reply to this post by Ben Gamari
Thanks for this debate.  (And thank you Austin for provoking it by articulating a medium term plan.)

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.

So I think the major trick we are missing is this:
 
   We don't know what the show-stopping bugs on a branch are

For example, here are three responses to Austin's message:

|  The only potential issue here is that not a single 7.8 release will be
|  able to bootstrap LLVM-only targets due to #9439. I'm not sure how

| 8960 looks rather serious and potentially makes all of 7.8 a no-go
| for some users.

|  We continue to use 7.2, at least partly because all newer versions of
|  ghc have had significant bugs that affect us

That's not good. Austin's message said about 7.8.4 "No particular pressure on any outstanding bugs to release immediately". There are several dozen tickets queued up on 7.8.4 (see here https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8.4), but 95% of them are "nice to have".  

So clearly the message is not getting through.  


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 development culture.)

 * We can only possibly do this if
   a) we can distinguish "show-stopping" from "nice to have"
   b) we get some help (thank you John Lato for implicitly offering)

I would define a "show-stopping" bug as one that simply prevents you from using the release altogether, or imposes a very large cost at the user end.

For mechanism I suggest this.  On the 7.8.4 status page (or in general, on the release branch page you want to influence), create a section "Show stoppers" with a list of the show-stopping bugs, including some English-language text saying who cares so much and why.  (Yes I know that it might be there in the ticket, but the impact is much greater if there is an explicit list of two 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 fixes that are harder.

Opinions?  I'm not making a ruling here!

Simon

|  -----Original Message-----
|  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Ben
|  Gamari
|  Sent: 04 October 2014 04:52
|  To: Austin Seipp; ghc-devs at haskell.org
|  Cc: Simon Marlow
|  Subject: Re: Tentative high-level plans for 7.10.1
|  
|  Austin Seipp <austin at well-typed.com> 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 tickets.
|  >
|  The only potential issue here is that not a single 7.8 release will be
|  able to bootstrap LLVM-only targets due to #9439. I'm not sure how
|  much of an issue this will be in practice but there should probably be
|  some discussion with packagers to ensure that 7.8 is skipped on
|  affected platforms lest users be stuck with no functional stage 0
|  compiler.
|  
|  Cheers,
|  
|  - Ben


Reply | Threaded
Open this post in threaded view
|

Tentative high-level plans for 7.10.1

p.k.f.holzenspies@utwente.nl
In reply to this post by Austin Seipp-5
Mmm... yes, you seem to have some strong points against LTS. People committing to an LTS-version aside from the further development of HEAD seems somewhat unlikely also...

I must say, though, significant API-changes with only minor version-bumps have bitten me also. Not sure we should want this.

Ph.


PS. Maybe long, but not too long, let alone TL;DR. Thanks for the clarity

________________________________________
From: mad.one at gmail.com <mad.one at gmail.com> on behalf of Austin Seipp <austin at well-typed.com>
Sent: 07 October 2014 02:45
To: John Lato
Cc: Johan Tibell; Holzenspies, P.K.F. (EWI); ghc-devs at haskell.org; Simon Marlow
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 absolutely-nothing to release announcement:

 1. Bump version, update configure.ac, tag.
 2. Build source tarball (this requires 1 build, but can be done very quickly).
 3. Make N binary builds for each platform (the most time consuming
part, as this requires heavy optimizations in the builds).
 4. Upload documentation for all libraries.
 5. Update webpage and upload binaries.
 6. Send announcement.
 7. Upload binaries from other systems later.

Herbert has graciously begun taking care of stewarding and uploading
the libraries. So, there are a few steps we could introduce to
alleviate this process technically in a few ways, but ultimately all
of these have to happen, pretty much (regardless of the automation
involved).

But I don't think this is the real problem.

The real problem is that GHC moves forward in terms of implementation
extremely, extremely quickly. It is not clear how to reconcile this
development pace with something like needing dozens of LTS releases
for a stable version. At least, not without a lot of concentrated
effort from almost every single developer. A lot of it can be
alleviated through social process perhaps, but it's not strictly
technical IMO.

What do I mean by that? I mean that:

 - We may introduce a feature in GHC version X.Y
 - That might have a bug, or other problems.
 - We may fix it, and in the process, fix up a few other things and
refactor HEAD, which will be GHC X.Y+2 eventually.
 - Repeat steps 2-3 a few times.
 - Now we want to backport the fixes for that feature in HEAD back to X.Y.
 - But GHC X.Y has *significantly* diverged from HEAD in that
timeframe, because of step 3 being repeated!

In other words: we are often so aggressive at refactoring code that
the *act* of backporting in and of itself can be complicated, and it
gets harder as time goes on - because often the GHC of a year ago is
so much different than the GHC of today.

As a concrete example of this, let's look at the changes between GHC
7.8.2 and GHC 7.8.3:

https://github.com/ghc/ghc/compare/ghc-7.8.2-release...ghc-7.8.3-release

There are about ~110 commits between 7.8.2 and 7.8.3. But as the 7.8
branch lived on, backporting fixes became significantly more complex.
In fact, I estimate close to 30 of those commits were NOT direct 7.8
requirements - but they were brought in because _actual fixes_ were
dependent on them, in non-trivial ways.

Take for example f895f33 by Simon PJ, which fixes #9023. The problem
with f895f33 is that by the time we fixed the bug in HEAD with that
commit, the history had changed significantly from the branch. In
order to get f895f33 to plant easily, I had to backport *at least* 12
to 15 other commits, which it was dependent upon, and commits those
commits were dependent upon, etc etc. I did not see any non-trivial
way to do this otherwise.

I believe at one point Gergo backported some of his fixes to 7.8,
which had since become 'non applicable' (and I thank him for that
greatly), but inevitably we instead brought along the few extra
changes anyway, since they were *still* needed for other fixes. And
some of them had API changes. So the choice was to rewrite 4 patches
for an old codebase completely (the work being done by two separate
people) or backport a few extra patches.

The above is obviously an extreme case. But it stands to reason this
would _only happen again_ with 7.8.4, probably even worse since more
months of development have gone by.

An LTS release would mandate things like no-API-changes-at-all, but
this significantly limits our ability to *actually* backport patches
sometimes, like the above, due to dependent changes. The alternative,
obviously, is to do what Gergo did and manually re-write such a fix
for the older branch. But that means we would have had to do that for
*every patch* in the same boat, including 2 or 3 other fixes we
needed!

Furthermore, while I am a release manager and do think I know a bit
about GHC, it is hopeless to expect me to know it all. I will
absolutely require coordinated effort to help develop 'retropatches'
that don't break API compatibility, from active developers who are
involved in their respective features. And they are almost all
volunteers! Simon and I are the only ones who wouldn't qualify on
that.

So - at what point does it stop becoming 'backporting fixes to older
versions' and instead become literally "working on the older version
of the compiler AND the new one in tandem"? Given our rate of churn
and change internally, this seems like it would be a significant
burden in general to ask of developers. If we had an LTS release of
GHC that lasted 3 years for example, that would mean developers are
expected to work on the current code of their own, *and their old code
for the next three years*. That is an absolutely, undeniably a _huge_
investment to ask of someone. It's not clear how many can actually
hold it (and I don't blame them).

This email is already a bit long (which is extremely unusual for my
emails, I'm sure you all know), but I just wanted to give some insight
on the process.

I think the technical/automation aspects are the easy part. We could
probably fully automate the GHC release process in days, if one or two
people worked on it dilligently. The hard part is actually balancing
the needs and time of users and developers, which is a complex
relationship.

On Mon, Oct 6, 2014 at 6:22 PM, John Lato <jwlato at gmail.com> wrote:

> On Mon, Oct 6, 2014 at 5:38 PM, Johan Tibell <johan.tibell at gmail.com> wrote:
>>
>> On Mon, Oct 6, 2014 at 11:28 AM, Herbert Valerio Riedel
>> <hvriedel at gmail.com> wrote:
>>>
>>> On 2014-10-06 at 11:03:19 +0200, p.k.f.holzenspies at 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 might actually be a Better Way.
>>>
>>> Maybe some of the commercial GHC users might be interested in donating
>>> the manpower to maintain older GHC versions. It's mostly a
>>> time-consuming QA & auditing process to maintain old GHCs.
>>
>>
>> What can we do to make that process cheaper? In particular, which are the
>> manual steps in making a new GHC release today?
>
>
> I would very much like to know this as well.  For ghc-7.8.3 there were a
> number of people volunteering manpower to finish up the release, but to the
> best of my knowledge those offers weren't taken up, which makes me think
> that the extra overhead for coordinating more people would outweigh any
> gains.  From the outside, it appears that the process/workflow could use
> some improvement, perhaps in ways that would make it simpler to divide up
> the workload.
>
> John L.
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>



--
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

Reply | Threaded
Open this post in threaded view
|

Tentative high-level plans for 7.10.1

Johan Tibell-2
In reply to this post by Simon Peyton Jones
On Tue, Oct 7, 2014 at 10:12 AM, Simon Peyton Jones <simonpj at microsoft.com>
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 probably
warrants a release. We should also move all those related bugs to the 7.8.4
milestone, so the impact of this issue is more clear.


> 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 development culture.)
>
>  * We can only possibly do this if
>    a) we can distinguish "show-stopping" from "nice to have"
>    b) we get some help (thank you John Lato for implicitly offering)
>

All sounds good to me. I can help with backporting bug fixes if needed. In
return I would encourage people to not mix bug fixes with "I rewrote the
compiler" commits. :)

I would define a "show-stopping" bug as one that simply prevents you from
> using the release altogether, or imposes a very large cost at the user end.
>

Agreed.

-- Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141007/74cbe72c/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Tentative high-level plans for 7.10.1

Johan Tibell-2
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
bug is a show stopper i.e. it affects lots of people/core libraries and
doesn't really have a good workaround, as turning of SpecConstr will most
likely make e.g. vector too slow.

On Tue, Oct 7, 2014 at 11:23 AM, Johan Tibell <johan.tibell at gmail.com>
wrote:

> On Tue, Oct 7, 2014 at 10:12 AM, Simon Peyton Jones <simonpj at microsoft.com
> > 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 probably
> warrants a release. We should also move all those related bugs to the 7.8.4
> milestone, so the impact of this issue is more clear.
>
>
>> 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 development culture.)
>>
>>  * We can only possibly do this if
>>    a) we can distinguish "show-stopping" from "nice to have"
>>    b) we get some help (thank you John Lato for implicitly offering)
>>
>
> All sounds good to me. I can help with backporting bug fixes if needed. In
> return I would encourage people to not mix bug fixes with "I rewrote the
> compiler" commits. :)
>
> I would define a "show-stopping" bug as one that simply prevents you from
>> using the release altogether, or imposes a very large cost at the user end.
>>
>
> Agreed.
>
> -- Johan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141007/659c0292/attachment.html>

12