Depending on the patch, the ci feedback may be fundamental. Eg some of the native code gen hackery im doing impacts a whole bunch of configurations I can’t do locally.
We could also have a wip/no-ci prefix ? Either way it’s certainlu true that we have finite resources and should endeavor to use them thoughtfully On Tue, Jan 8, 2019 at 5:32 AM Matthew Pickering < [email protected]> wrote: > I agree with Omer that we shouldn't encourage people to push wip branches > to ghc/ghc. It wastes resources and pollutes the repo with lots of branches > that will invariably not be deleted. > > I would rather we use absolute paths in the submodule file as I have spent > far longer than I expected trying to get git to use the right submodule in > the past when operating on forks. > > Matt > > > On Tue, 8 Jan 2019, 10:09 Gabor Greif <[email protected] wrote: > >> You can specify `[skip ci]` in the commit message if you don't want to >> run the pipeline. When you are done, just amend your commit with the >> finalised note. >> >> Gabor >> >> On 1/8/19, Ömer Sinan Ağacan <[email protected]> wrote: >> >> As I mention in the documentation, those with commits bits should feel >> >> free to push branches to ghc/ghc. >> > >> > This is sometimes not ideal as it wastes GHC's CI resources. For >> example I >> > make >> > a lot of WIP commits to my work branches, and I don't want to keep CI >> > machines >> > busy for those. >> > >> > Ömer >> > >> > Ben Gamari <[email protected]>, 8 Oca 2019 Sal, 04:53 tarihinde şunu >> yazdı: >> >> >> >> Moritz Angermann <[email protected]> writes: >> >> >> >> > Can’t we have absolute submodule paths? Wouldn’t that elevate the >> >> > issue? >> >> > >> >> Perhaps; I mentioned this possibility in my earlier response. It's not >> >> clear which trade-off is better overall, however. >> >> >> >> > When we all had branches on ghc/ghc this >> >> > was not an issue. >> >> > >> >> As I mention in the documentation, those with commits bits should feel >> >> free to push branches to ghc/ghc. >> >> >> >> Cheers, >> >> >> >> - Ben >> >> _______________________________________________ >> >> ghc-devs mailing list >> >> [email protected] >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > _______________________________________________ >> > ghc-devs mailing list >> > [email protected] >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > >> _______________________________________________ >> ghc-devs mailing list >> [email protected] >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > _______________________________________________ > ghc-devs mailing list > [email protected] > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >
_______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
