<div dir="ltr">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<div>)</div><div><br></div><div>$ git clone -b ghc-7.8 git://<a href="http://git.haskell.org/ghc.git">git.haskell.org/ghc.git</a> ghc-7.8TREE<br></div><div>$ cd ghc-7.8TREE/<br></div><div>$ ./sync-all get -b ghc-7.8<br></div><div><br></div><div>(theres no need for a lot of this with HEAD)</div><div><br></div><div>that will checkout a working tree of 7.8 head (unless i'm missing a step)</div><div>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 ! )</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 7, 2014 at 7:56 PM, John Lato <span dir="ltr"><<a href="mailto:jwlato@gmail.com" target="_blank">jwlato@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Ok, if the ghc devs decide to do a 7.8.4 release, I will explicitly commit to helping backport patches.<div><br></div><div>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:</div><div><br></div><div>checkout the 7.8.4 release branch (which branch is it? ghc-7.8?)</div><div>git cherry-pick the desired commit(s)</div><div>? (make a phab request for ghc-hq to review?)</div><div>update Trac with what you've done</div><div><br></div><div>(or if this is already documented somewhere, please point me to it).</div><div><br></div><div>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.</div><div><br></div><div>Cheers,</div><div>John</div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 7, 2014 at 4:12 PM, Simon Peyton Jones <span dir="ltr"><<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks for this debate. (And thank you Austin for provoking it by articulating a medium term plan.)<br>
<br>
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.<br>
<br>
So I think the major trick we are missing is this:<br>
<br>
We don't know what the show-stopping bugs on a branch are<br>
<br>
For example, here are three responses to Austin's message:<br>
<span><br>
| The only potential issue here is that not a single 7.8 release will be<br>
| able to bootstrap LLVM-only targets due to #9439. I'm not sure how<br>
<br>
</span><span>| 8960 looks rather serious and potentially makes all of 7.8 a no-go<br>
| for some users.<br>
<br>
</span><span>| We continue to use 7.2, at least partly because all newer versions of<br>
| ghc have had significant bugs that affect us<br>
<br>
</span>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 <a href="https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8.4" target="_blank">https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8.4</a>), but 95% of them are "nice to have".<br>
<br>
So clearly the message is not getting through.<br>
<br>
<br>
My conclusion<br>
<br>
* I think we (collectively!) should make a serious attempt to fix show-stopping<br>
bugs on a major release branch. (I agree that upgrading to the next major<br>
release often simply brings in a new wave of bugs because of GHC's<br>
rapid development culture.)<br>
<br>
* We can only possibly do this if<br>
a) we can distinguish "show-stopping" from "nice to have"<br>
b) we get some help (thank you John Lato for implicitly offering)<br>
<br>
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.<br>
<br>
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.)<br>
<br>
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.<br>
<br>
Opinions? I'm not making a ruling here!<br>
<span><font color="#888888"><br>
Simon<br>
</font></span><span><br>
| -----Original Message-----<br>
| From: ghc-devs [mailto:<a href="mailto:ghc-devs-bounces@haskell.org" target="_blank">ghc-devs-bounces@haskell.org</a>] On Behalf Of Ben<br>
| Gamari<br>
| Sent: 04 October 2014 04:52<br>
| To: Austin Seipp; <a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
| Cc: Simon Marlow<br>
| Subject: Re: Tentative high-level plans for 7.10.1<br>
|<br>
</span><div><div>| Austin Seipp <<a href="mailto:austin@well-typed.com" target="_blank">austin@well-typed.com</a>> writes:<br>
|<br>
| snip.<br>
|<br>
| ><br>
| > We do not believe we will ship a 7.8.4 at all, contrary to what you<br>
| > may have seen on Trac - we never decided definitively, but there is<br>
| > likely not enough time. Over the next few days, I will remove the<br>
| > defunct 7.8.4 milestone, and re-triage the assigned tickets.<br>
| ><br>
| The only potential issue here is that not a single 7.8 release will be<br>
| able to bootstrap LLVM-only targets due to #9439. I'm not sure how<br>
| much of an issue this will be in practice but there should probably be<br>
| some discussion with packagers to ensure that 7.8 is skipped on<br>
| affected platforms lest users be stuck with no functional stage 0<br>
| compiler.<br>
|<br>
| Cheers,<br>
|<br>
| - Ben<br>
<br>
</div></div><div><div>_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/ghc-devs" target="_blank">http://www.haskell.org/mailman/listinfo/ghc-devs</a><br>
</div></div></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/ghc-devs" target="_blank">http://www.haskell.org/mailman/listinfo/ghc-devs</a><br>
<br></blockquote></div><br></div>