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 <[email protected]> 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 <[email protected]> > 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:[email protected]] On Behalf Of Ben >> | Gamari >> | Sent: 04 October 2014 04:52 >> | To: Austin Seipp; [email protected] >> | Cc: Simon Marlow >> | Subject: Re: Tentative high-level plans for 7.10.1 >> | >> | Austin Seipp <[email protected]> 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 >> [email protected] >> http://www.haskell.org/mailman/listinfo/ghc-devs >> > > > _______________________________________________ > ghc-devs mailing list > [email protected] > http://www.haskell.org/mailman/listinfo/ghc-devs > >
_______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
