RFC: Phabricator for patches and code review

[Richard Eisenberg]

Piggybacking a bit on Ömer's point:

It is often the case that something flies by that I can fix in a few moments (for example, #9163) but that I have to defer until I have enough time for a GHC hacking session. Making even a tiny patch requires that I'm up-to-date, that my unchanged tree compiles (and, if I have time, validates!), and then, after the patch, that everything validates again. This generally means that I don't touch GHC unless I have 3+ hours *that day* to devote to GHC -- there are enough commits that I don't want things getting too stale if I can't validate the same day I update. Compounding the problem, my desire for efficiency leads me to accumulate GHC tasks, meaning that my time requirements become even worse, making it harder to get anything done.

It sounds like, perhaps, Phab isn't the answer, but a way to create a lightweight, *untested* patch that doesn't require all of this would be simply wonderful. Experience has told me even to be scared of just adding comments without a validate!

Is there such a facility now? How hard would it be to create one?

Richard

On Jun 6, 2014, at 8:59 AM, Austin Seipp <austin at well-typed.com> wrote:

> No, at the moment Phabricator is not integrated with any testing
> functionality. It could be, but that would be a bit of work I think to
> integrate with GHC's ./validate process. It would be nice to have
> long-term, however, but I don't think it's necessary right now - I run
> ./validate before every push out anyway just in case.
> 
> If you do need a machine to help run builds, a recommendation: sign up
> for AWS. A GHC build can be done in < 1hr on those machines, and an
> x1.xlarge for example would cost you about .28c USD to run for that
> period. It's less than optimal, but I'm not the only one who has
> resorted to this on less-than-adequate machines...
> 
> Another recommendation is to make sure you've got the right build
> settings, which can have a pretty dramatic impact on build times. See
> here: https://ghc.haskell.org/trac/ghc/wiki/Building/Hacking and also
> https://ghc.haskell.org/trac/ghc/wiki/Building/Using#HowtomakeGHCbuildquickly
> 
> On Fri, Jun 6, 2014 at 3:13 AM, Ömer Sinan Ağacan <omeragacan at gmail.com> wrote:
>> 2014-06-06 7:05 GMT+03:00 Austin Seipp <austin at well-typed.com>:
>>> 2) Phabricator in particular makes it very easy to submit patches for
>>> review. To submit a patch, I just run the command 'arc diff' and it
>>> Does The Right Thing. It also makes it easy to ensure people are
>>> *alerted* when a patch might be relevant to them.
>> 
>> This sounds really good. I was thinking about sending an email about
>> this for a while now. I'm reading some parts of GHC and there are lots
>> of small patches I'd like to submit for reviews. Most of the time
>> these are <10 lines of changes. But trac makes everything so hard and
>> the interface is so horrible, I'm ending up not sending the patch.
>> Also, testing is a huge problem for me. I can't test GHC on my
>> laptop(which is my only development environment) because it takes
>> forever to finish.
>> 
>> With something like Github and a CI server(Jenkins/Travis/whatever)
>> integrated to the Github repository that runs tests on pull request,
>> it would be super easy for new contributors to submit small patches.
>> 
>> As far as I can understand(altough currently I can't see how to send a
>> patch) Phabricator helps sending pull requests/patches, but does it
>> help with testing too?
>> 
>> ---
>> Ömer Sinan Ağacan
>> http://osa1.net
>> 
> 
> 
> 
> -- 
> Regards,
> 
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>