Tentative high-level plans for 7.10.1

Wed Oct 8 00:13:01 UTC 2014

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-7.8TREE
$ cd ghc-7.8TREE/
$ ./sync-all   get -b ghc-7.8

(theres no need for a lot of this with HEAD)

that will checkout a working tree of 7.8 head (unless i'm missing a step)
I Believe arc/phab will work correctly on top of this though. (I certainly
used phab to get a patch or so into 7.8.3 ! )

On Tue, Oct 7, 2014 at 7:56 PM, John Lato <jwlato at gmail.com> wrote:

> Ok, if the ghc devs decide to do a 7.8.4 release, I will explicitly commit
> to helping backport patches.
>
> However, I don't know how to do so.  Therefore, I'm going to ask Austin
> (as he's probably the most knowledgeable) to update the 7.8.4 wiki page
> with the process people should use to contribute backports.  I'm guessing
> it's probably something like this:
>
> checkout the 7.8.4 release branch (which branch is it? ghc-7.8?)
> git cherry-pick the desired commit(s)
> ? (make a phab request for ghc-hq to review?)
> update Trac with what you've done
>
> (or if this is already documented somewhere, please point me to it).
>
> Unfortunately this doesn't have any way of showing that I'm working on a
> specific backport/merge, so there's potential for duplicate work, which
> isn't great.  I also agree with Nicolas that it's likely possible to make
> better use of git to help with this sort of work, but that's a decision for
> ghc hq so I won't say any more on that.
>
> Cheers,
> John
>
>
> On Tue, Oct 7, 2014 at 4:12 PM, Simon Peyton Jones <simonpj at microsoft.com>
> wrote:
>
>> 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
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>
>
> _______________________________________________
> 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/20141007/8ef8ca4a/attachment-0001.html>