Simon Peyton Jones <simo...@microsoft.com> 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 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.) > Writing a bit more text sounds like a small price to pay to ensure that show-stoppers don't fall through the cracks. It's also nice to have a high-level view of what is being considered for release.
I've added some text for #9439 [1]. > 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. > This seems quite reasonable. Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8.4#a9439:LLVMmanglermanglestoovigorously
pgphtEsIlkg2H.pgp
Description: PGP signature
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
