Re: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion

[Simon Marlow]

I added a description of the workflow for multiple dependent diffs here:
https://ghc.haskell.org/trac/ghc/wiki/Phabricator#Workingwithmultipledependentdiffs

Please let me know if anything doesn't make sense.  Note that I never let
arc squash my commits, keeping commits 1:1 with diffs makes things a lot
simpler.


On 1 October 2016 at 21:49, Brandon Allbery  wrote:

> On Sat, Oct 1, 2016 at 4:47 PM, Simon Marlow  wrote:
>
>> A nice trick for dealing with stacked diffs in Phabricator is to use "git
>> rebase -i" to modify diffs in the middle of the stack.  You can also insert
>> "x arc diff" between lines to automatically update later diffs on
>> Phabricator after a rebase lower down the stack.
>>
>> You only need a single branch for the whole stack, and continually rebase
>> it.  I also push the whole branch to github to get Travis to build it, but
>> that's optional.
>>
>
> Perhaps someone could put a sample workflow on (one of...) the wiki(s).
>
> --
> brandon s allbery kf8nh   sine nomine
> associates
> allber...@gmail.com
> ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion

[Brandon Allbery]

On Sat, Oct 1, 2016 at 4:47 PM, Simon Marlow  wrote:

> A nice trick for dealing with stacked diffs in Phabricator is to use "git
> rebase -i" to modify diffs in the middle of the stack.  You can also insert
> "x arc diff" between lines to automatically update later diffs on
> Phabricator after a rebase lower down the stack.
>
> You only need a single branch for the whole stack, and continually rebase
> it.  I also push the whole branch to github to get Travis to build it, but
> that's optional.
>

Perhaps someone could put a sample workflow on (one of...) the wiki(s).

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion

[Simon Marlow]

A nice trick for dealing with stacked diffs in Phabricator is to use "git
rebase -i" to modify diffs in the middle of the stack.  You can also insert
"x arc diff" between lines to automatically update later diffs on
Phabricator after a rebase lower down the stack.

You only need a single branch for the whole stack, and continually rebase
it.  I also push the whole branch to github to get Travis to build it, but
that's optional.

Cheers
Simon

On 29 September 2016 at 03:27, Moritz Angermann 
wrote:

>
> >> Hence you can go wild on your local branches (use what ever
> >> development model suites your needs) and get one final squashed commit
> >> with an extensive summary.
> >>
> > Sure, but this leads to generally unreviewable patches IMHO. In order to
> > stay sane I generally split up my work into a set of standalone patches
> > with git rebase and then create a Diff of each of these commits.
> > Phabricator supports this by having a notion of dependencies between
> > Diffs, but arcanist has no sensible scheme for taking a branch and
> > conveniently producing a series of Diffs.
>
> Yes, this has been a constant source of frustration for us as well. Dealing
> with dependent diffs is just plain painful with arc :( What I usually end
> up
> doing, and I assume that’s what you are describing is:
>
> Turning
>
> A -- B -- C -- D -- E -- F -- origin/master
> ^
> HEAD
>
> into:
>
> branch B1:  E -- F -- origin/master
>   /
> branch B2:  C -- D
>   /
> branch B3: A -- B
>
> and producing three diffs:
>
> $ git checkout E
> $ arc diff origin/master # producing D1
>
> $ git checkout C
> $ arc diff B1 # adding “depends on D1" into the summary field
>
> $ git checkout A
> $ git diff B2 # adding “depends on D2” into the summary field
>
> and then rebase B2 and B3 when changes to D1 on B1 are necessary.
>
> Running `arc patch` with dependent diffs often resulted in trouble;
> this seems to be getting better with the staging areas though.
>
> So clearly we can see there are drawbacks.  All I wanted to say in
> the previous email was essentially that from my experience frustration
> with arc often came from trying to make arc be git.
>
> Cheers,
>  Moritz
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion

[Ben Gamari]

Matthew Pickering  writes:

> Thanks for the useful data point Mathieu. I think it should also be
> noted that GHC contributions spiked after switching to phabricator so
> it could just be the effect of moving to *some* code review tool.
> Could you perhaps summarise the salient points in the LLVM thread? It
> is very long with lots of discussion points.

As far as I know the LLVM folks were merely considering moving from SVN
to Git, using GitHub to host their reposistory. I don't believe that
moving to GitHub for issue tracking, code review, or any other
functionality was ever seriously on the table.

Cheers,

- Ben



signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion

[Matthew Pickering]

Thanks for the useful data point Mathieu. I think it should also be
noted that GHC contributions spiked after switching to phabricator so
it could just be the effect of moving to *some* code review tool.
Could you perhaps summarise the salient points in the LLVM thread? It
is very long with lots of discussion points.

FWIW, I think that we should accept pull requests but only if they are
mirrored and reviewed on phabricator.

This is important for three reasons:

1. Reviewers only need to look in one place and can clearly see when
they are expected to review. Herald rules will also not trigger if a
pull request is solely dealt with on github
which could mean the right eyes don't land on the ticket.
2. Pull requests (differentials) are able to be referred to by their
unique differential number rather than the pull request identifier
which clashes with trac ticket numbers.
3. Differentials integrate (and are able to be integrated) with the
existing infrastructure. I hope that in the future we improve this
integration by moving the issue tracker to maniphest.

Facebook have a bot which does the mirroring for some of their
repositories but it isn't open-sourced.

I believe we should be trying to consolidate rather than spread
everything even thinner.

Matt



On Thu, Sep 29, 2016 at 9:55 PM, Boespflug, Mathieu  wrote:
> Hi Richard!
>
> thanks for creating the pull request with a full proposal. You beat me to it
> - tried writing up much the same before stopping for dinner, essentially
> capturing just one of the points in Moritz's earlier (large) proposal.
> Moritz, I would encourage you like Richard did earlier to split the
> remaining points in your proposal into separate PR's too.
>
> So Richard, I created a PR to your PR to add in a little bit more detail:
> keeping the two mirrors in sync, role of the release manager to ensure that
> adequate reviewers get identified so that patches don't go unnoticed by an
> interested party who'd specifically want to review the patch on Phabricator,
> etc.
>
> https://github.com/goldfirere/ghc-proposals/pull/1
>
> I also moved one of the two choices you mention to the "alternatives"
> section of the document, thinking that's the pupose of the section.
>
> On another note, I solicited an experience report from Gabriel Scherer
> earlier this week. The Ocaml community likewise pondered using GitHub back
> in 2014, and in fact lauched an experiment to that effect.  So I was curious
> to hear how it went after 2 years of data.
>
> You can see the announcement here:
>
> http://thread.gmane.org/gmane.comp.lang.ocaml.platform/30
>
> Gabriel tells me that the initial situation for Ocaml was different from
> that of GHC: they had no formal code review tool in use, but would swap
> around patches on the Mantis issue tracker. Be it as it may, it's
> interesting to note just how much the number of contributions to Ocaml has
> increased in recent years, after this experiment started:
>
> https://github.com/ocaml/ocaml/graphs/contributors
>
> This experiment is today considered a big success. A key ingredient I gather
> is that Gabriel volunteered to triage the GitHub PR's and play the
> go-between to make sure all Mantis users were aware of any proposed changes
> relevant to them.
>
> The key insight I would put forth here is that how-to-accept-patches and
> where-to-review-them should be an agreement between the contributor and the
> assigned reviewer(s), in particular for trivial changes. For any given
> patch, provided the reviewer(s) is/are game, and provided all protential
> reviewers are made aware of its existence, it shouldn't matter much whether
> the patch came from Trac, Phabricator or GitHub.
>
> PS: Gabriel was very kind to also point out that the LLVM community has been
> big users of Phabricator and pondering introducing GitHub into the mix too.
> The discussion there should be relevant to this thread:
>
> http://lists.llvm.org/pipermail/llvm-dev/2016-May/100310.html
>
> Best,
>
> --
> Mathieu Boespflug
> Founder at http://tweag.io.
>
> --
> Mathieu Boespflug
> Founder at http://tweag.io.
>
> On 29 September 2016 at 20:55, Richard Eisenberg 
> wrote:
>>
>> I have tried to gather the ideas from this thread into a formal proposal:
>> https://github.com/ghc-proposals/ghc-proposals/pull/11
>>
>> Please feel free to make suggestions to improve this, especially if I've
>> captured anyone's contributions incorrectly.
>>
>> -=-=-=-=-=-=-=-=-=-=-
>> Richard A. Eisenberg
>> Asst. Prof. of Computer Science
>> Bryn Mawr College
>> Bryn Mawr, PA, USA
>> cs.brynmawr.edu/~rae
>>
>> > On Sep 29, 2016, at 10:20 AM, Christopher Allen 
>> > wrote:
>> >
>> >> Instead perhaps GitHub's new review system may be the way forward for
>> >> GHC. It allows you to easily use git in the way it's meant to be used.
>> >
>> > Many problems are caused by letting your inner tinkerer/genius tailor
>> > dictate how things should be dealt with. Better to cut the gordian
>> > knot. I think Michael's right.

Re: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion

[Boespflug, Mathieu]

Hi Richard!

thanks for creating the pull request with a full proposal. You beat me to
it - tried writing up much the same before stopping for dinner, essentially
capturing just one of the points in Moritz's earlier (large) proposal.
Moritz, I would encourage you like Richard did earlier to split the
remaining points in your proposal into separate PR's too.

So Richard, I created a PR to your PR to add in a little bit more detail:
keeping the two mirrors in sync, role of the release manager to ensure that
adequate reviewers get identified so that patches don't go unnoticed by an
interested party who'd specifically want to review the patch on
Phabricator, etc.

https://github.com/goldfirere/ghc-proposals/pull/1

I also moved one of the two choices you mention to the "alternatives"
section of the document, thinking that's the pupose of the section.

On another note, I solicited an experience report from Gabriel Scherer
earlier this week. The Ocaml community likewise pondered using GitHub back
in 2014, and in fact lauched an experiment to that effect.  So I was
curious to hear how it went after 2 years of data.

You can see the announcement here:

http://thread.gmane.org/gmane.comp.lang.ocaml.platform/30

Gabriel tells me that the initial situation for Ocaml was different from
that of GHC: they had no formal code review tool in use, but would swap
around patches on the Mantis issue tracker. Be it as it may, it's
interesting to note just how much the number of contributions to Ocaml has
increased in recent years, after this experiment started:

https://github.com/ocaml/ocaml/graphs/contributors

This experiment is today considered a big success. A key ingredient I
gather is that Gabriel volunteered to triage the GitHub PR's and play the
go-between to make sure all Mantis users were aware of any proposed changes
relevant to them.

The key insight I would put forth here is that how-to-accept-patches and
where-to-review-them should be an agreement between the contributor and the
assigned reviewer(s), in particular for trivial changes. For any given
patch, provided the reviewer(s) is/are game, and provided all protential
reviewers are made aware of its existence, it shouldn't matter much whether
the patch came from Trac, Phabricator or GitHub.

PS: Gabriel was very kind to also point out that the LLVM community has
been big users of Phabricator and pondering introducing GitHub into the mix
too. The discussion there should be relevant to this thread:

http://lists.llvm.org/pipermail/llvm-dev/2016-May/100310.html

Best,

--
Mathieu Boespflug
Founder at http://tweag.io.

--
Mathieu Boespflug
Founder at http://tweag.io.

On 29 September 2016 at 20:55, Richard Eisenberg 
wrote:

> I have tried to gather the ideas from this thread into a formal proposal:
> https://github.com/ghc-proposals/ghc-proposals/pull/11
>
> Please feel free to make suggestions to improve this, especially if I've
> captured anyone's contributions incorrectly.
>
> -=-=-=-=-=-=-=-=-=-=-
> Richard A. Eisenberg
> Asst. Prof. of Computer Science
> Bryn Mawr College
> Bryn Mawr, PA, USA
> cs.brynmawr.edu/~rae
>
> > On Sep 29, 2016, at 10:20 AM, Christopher Allen 
> wrote:
> >
> >> Instead perhaps GitHub's new review system may be the way forward for
> GHC. It allows you to easily use git in the way it's meant to be used.
> >
> > Many problems are caused by letting your inner tinkerer/genius tailor
> > dictate how things should be dealt with. Better to cut the gordian
> > knot. I think Michael's right.
> >
> > On Thu, Sep 29, 2016 at 5:05 AM, Michael Sloan 
> wrote:
> >>
> >>
> >> On Wednesday, September 28, 2016, Eric Seidel  wrote:
> >>>
> >>> On Wed, Sep 28, 2016, at 18:37, Ben Gamari wrote:
>  Moritz Angermann  writes:
> 
> > All that arc essentially does is, compute the diff from an offset
> > (e.g. master) to the current HEAD and upload that to a new or
> existing
> > (--update) differential. It also adds some meta information about the
> > range, such that arc patch supposedly knows into which commit to
> apply
> > the patch to.
> >
>  Sure, but this leads to generally unreviewable patches IMHO. In order
> to
>  stay sane I generally split up my work into a set of standalone
> patches
>  with git rebase and then create a Diff of each of these commits.
>  Phabricator supports this by having a notion of dependencies between
>  Diffs, but arcanist has no sensible scheme for taking a branch and
>  conveniently producing a series of Diffs.
> >>>
> >>> I completely understand how this would be frustrating for core
> >>> contributors (more specifically for people submitting large patches),
> >>> but for new or casual contributors it's actually quite freeing. I don't
> >>> have to worry about how messy my local history gets, because arc will
> >>> throw it all away regardless! It absolves me of an extra
> responsibility,
> >>> and lowers the barrier to contributing.
> >>
> >>
> >> I dislike this work

Re: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion

[Richard Eisenberg]

I have tried to gather the ideas from this thread into a formal proposal: 
https://github.com/ghc-proposals/ghc-proposals/pull/11

Please feel free to make suggestions to improve this, especially if I've 
captured anyone's contributions incorrectly.

-=-=-=-=-=-=-=-=-=-=-
Richard A. Eisenberg
Asst. Prof. of Computer Science
Bryn Mawr College
Bryn Mawr, PA, USA
cs.brynmawr.edu/~rae

> On Sep 29, 2016, at 10:20 AM, Christopher Allen  wrote:
> 
>> Instead perhaps GitHub's new review system may be the way forward for GHC. 
>> It allows you to easily use git in the way it's meant to be used.
> 
> Many problems are caused by letting your inner tinkerer/genius tailor
> dictate how things should be dealt with. Better to cut the gordian
> knot. I think Michael's right.
> 
> On Thu, Sep 29, 2016 at 5:05 AM, Michael Sloan  wrote:
>> 
>> 
>> On Wednesday, September 28, 2016, Eric Seidel  wrote:
>>> 
>>> On Wed, Sep 28, 2016, at 18:37, Ben Gamari wrote:
 Moritz Angermann  writes:
 
> All that arc essentially does is, compute the diff from an offset
> (e.g. master) to the current HEAD and upload that to a new or existing
> (--update) differential. It also adds some meta information about the
> range, such that arc patch supposedly knows into which commit to apply
> the patch to.
> 
 Sure, but this leads to generally unreviewable patches IMHO. In order to
 stay sane I generally split up my work into a set of standalone patches
 with git rebase and then create a Diff of each of these commits.
 Phabricator supports this by having a notion of dependencies between
 Diffs, but arcanist has no sensible scheme for taking a branch and
 conveniently producing a series of Diffs.
>>> 
>>> I completely understand how this would be frustrating for core
>>> contributors (more specifically for people submitting large patches),
>>> but for new or casual contributors it's actually quite freeing. I don't
>>> have to worry about how messy my local history gets, because arc will
>>> throw it all away regardless! It absolves me of an extra responsibility,
>>> and lowers the barrier to contributing.
>> 
>> 
>> I dislike this workflow because I am already used to doing a lot of git
>> rebasing / amending / auto squashing.  So using arc means taking away my
>> ability to write multi commit stories of how the change was crafted. For
>> large changes there are often multiple logical inter related steps.
>> Squashing them into one big commit makes it much harder to review.  I can
>> easily do that myself by marking everything as squash in a rebase. It feels
>> like arcanist is just taking away power, not giving it (note i have not used
>> it much - voice of a newbie here)
>> 
>> I am beginning to change my feelings on this, away from thinking of GitHub
>> as an auxilliary source of didferentials.  Instead perhaps GitHub's new
>> review system may be the way forward for GHC. It allows you to easily use
>> git in the way it's meant to be used.
>> 
>> -Michael
>> 
>>> 
>>> 
>>> It would be nice to support both workflows though :)
>>> ___
>>> ghc-devs mailing list
>>> ghc-devs@haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> 
>> 
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> 
> 
> 
> 
> -- 
> Chris Allen
> Currently working on http://haskellbook.com
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion

[Christopher Allen]

>Instead perhaps GitHub's new review system may be the way forward for GHC. It 
>allows you to easily use git in the way it's meant to be used.

Many problems are caused by letting your inner tinkerer/genius tailor
dictate how things should be dealt with. Better to cut the gordian
knot. I think Michael's right.

On Thu, Sep 29, 2016 at 5:05 AM, Michael Sloan  wrote:
>
>
> On Wednesday, September 28, 2016, Eric Seidel  wrote:
>>
>> On Wed, Sep 28, 2016, at 18:37, Ben Gamari wrote:
>> > Moritz Angermann  writes:
>> >
>> > > All that arc essentially does is, compute the diff from an offset
>> > > (e.g. master) to the current HEAD and upload that to a new or existing
>> > > (--update) differential. It also adds some meta information about the
>> > > range, such that arc patch supposedly knows into which commit to apply
>> > > the patch to.
>> > >
>> > Sure, but this leads to generally unreviewable patches IMHO. In order to
>> > stay sane I generally split up my work into a set of standalone patches
>> > with git rebase and then create a Diff of each of these commits.
>> > Phabricator supports this by having a notion of dependencies between
>> > Diffs, but arcanist has no sensible scheme for taking a branch and
>> > conveniently producing a series of Diffs.
>>
>> I completely understand how this would be frustrating for core
>> contributors (more specifically for people submitting large patches),
>> but for new or casual contributors it's actually quite freeing. I don't
>> have to worry about how messy my local history gets, because arc will
>> throw it all away regardless! It absolves me of an extra responsibility,
>> and lowers the barrier to contributing.
>
>
> I dislike this workflow because I am already used to doing a lot of git
> rebasing / amending / auto squashing.  So using arc means taking away my
> ability to write multi commit stories of how the change was crafted. For
> large changes there are often multiple logical inter related steps.
> Squashing them into one big commit makes it much harder to review.  I can
> easily do that myself by marking everything as squash in a rebase. It feels
> like arcanist is just taking away power, not giving it (note i have not used
> it much - voice of a newbie here)
>
> I am beginning to change my feelings on this, away from thinking of GitHub
> as an auxilliary source of didferentials.  Instead perhaps GitHub's new
> review system may be the way forward for GHC. It allows you to easily use
> git in the way it's meant to be used.
>
> -Michael
>
>>
>>
>> It would be nice to support both workflows though :)
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>



-- 
Chris Allen
Currently working on http://haskellbook.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion

[Michael Sloan]

On Wednesday, September 28, 2016, Eric Seidel  wrote:

> On Wed, Sep 28, 2016, at 18:37, Ben Gamari wrote:
> > Moritz Angermann > writes:
> >
> > > All that arc essentially does is, compute the diff from an offset
> > > (e.g. master) to the current HEAD and upload that to a new or existing
> > > (--update) differential. It also adds some meta information about the
> > > range, such that arc patch supposedly knows into which commit to apply
> > > the patch to.
> > >
> > Sure, but this leads to generally unreviewable patches IMHO. In order to
> > stay sane I generally split up my work into a set of standalone patches
> > with git rebase and then create a Diff of each of these commits.
> > Phabricator supports this by having a notion of dependencies between
> > Diffs, but arcanist has no sensible scheme for taking a branch and
> > conveniently producing a series of Diffs.
>
> I completely understand how this would be frustrating for core
> contributors (more specifically for people submitting large patches),
> but for new or casual contributors it's actually quite freeing. I don't
> have to worry about how messy my local history gets, because arc will
> throw it all away regardless! It absolves me of an extra responsibility,
> and lowers the barrier to contributing.


I dislike this workflow because I am already used to doing a lot of git
rebasing / amending / auto squashing.  So using arc means taking away my
ability to write multi commit stories of how the change was crafted. For
large changes there are often multiple logical inter related steps.
Squashing them into one big commit makes it much harder to review.  I can
easily do that myself by marking everything as squash in a rebase. It feels
like arcanist is just taking away power, not giving it (note i have not
used it much - voice of a newbie here)

I am beginning to change my feelings on this, away from thinking of GitHub
as an auxilliary source of didferentials.  Instead perhaps GitHub's new
review system may be the way forward for GHC. It allows you to easily use
git in the way it's meant to be used.

-Michael


>
> It would be nice to support both workflows though :)
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org 
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion

[David Turner]

Hi,

You can alter the content of a GitHub PR after its initial creation. The
semantics of a PR is "please merge my branch named B into your repo" where
the branch B is a mutable pointer to a commit.

A workflow I've used a few times is to craft a nice sequence of commits for
review and, once accepted, updated the PR to a squashed version of the
same. Not that I like squashing, but that's what upstream wanted.

In fact, the mutability of a PR is something you have to be a bit careful
about on GitHub as you may not be accepting what you reviewed. It doesn't
seem very easy to see how the branch has changed over time: there is no
audit facility. I'd have thought the tooling discussed earlier should be
able to take care of this problem.

Cheers,

On 28 Sep 2016 09:44, "Simon Marlow"  wrote:

> Well, let's be careful here.  I like the idea, but it's not a complete
> solution for people who don't want to use arc, because you can't revise a
> patch after submission in response to reviews, you would have to open a new
> PR.
>
> Perhaps you could build something that would allow revisions to PRs too...
> that would be cool.
>
> Cheers
> Simon
>
> On 28 September 2016 at 03:22, Michael Sloan  wrote:
>
>> Exactly!  So we will be using Phabricator for the review process, but
>> with the github PRs you can use plain git.  This means that new
>> contributors will only need to learn about phabricator, and arc will
>> be non-mandatory though probably recommended.
>>
>> Glad you like the idea :)
>>
>> -Michael
>>
>> On Tue, Sep 27, 2016 at 6:47 PM, Richard Eisenberg 
>> wrote:
>> > So you're suggesting that GitHub would function as a sort of alternate
>> front-end to Phab. While I've grown to enjoy Phab quite a bit, I still
>> strongly dislike arc, which tries to be too clever for my tastes. Provided
>> the integration works smoothly, I quite like this idea.
>> >
>> > Richard
>> >
>> >> On Sep 27, 2016, at 5:32 PM, Michael Sloan  wrote:
>> >>
>> >> You're welcome Richard!  I look forward to helping make it happen.  In
>> >> the other thread, Alexander Vershilov mentioned that we might instead
>> >> consider the following more straightforward workflow:
>> >>
>> >> 0) Have a bot that watches github for PRs.
>> >> 1) Submit whatever you want to github as a PR.
>> >> 2) It will be automatically closed and migrated to Phabricator.  I
>> >> would like it to automatically create a Phabricator account if you do
>> >> not already have one.  The message from the bot will tell you about
>> >> this action, and explain how to log in, perhaps even linking to
>> >> resources about Phabricator.
>> >>
>> >> Is this worth it?  I think it is for the one-off cases.  However, you
>> >> will have to be prepared that this means that people won't have
>> >> arcanist setup, and therefore are less likely to actually iterate on
>> >> their PR.  Perhaps we should extend this to the following:
>> >>
>> >> 3) Subsequent pushes to the branch for the PR will update the
>> >> Phabricator differential as if you had pushed via Arcanist.  I think
>> >> with this in place, we would have a fully streamlined system that
>> >> allows people to use their familiar GitHub workflows, without needing
>> >> to learn Arcanist.  Interactions would then still occur on , of
>> >> course.
>> >>
>> >> This way, GHC HQ doesn't even need to learn to use this new "ghc-hub"
>> >> tool!  Could name the bot that, though!
>> >>
>> >> Thoughts?  I think it would be great for this to be proposed formally
>> >> soon so that we can make it happen.  I am eager to be able to use my
>> >> normal git workflows, as my little experience with Arcanist induced
>> >> some head-scratching.  Not the fault of the tool, just a result of
>> >> lack of familiarity.
>> >>
>> >> -Michael
>> >>
>> >> On Tue, Sep 27, 2016 at 8:46 AM, Richard Eisenberg <
>> r...@cs.brynmawr.edu> wrote:
>> >>> To sum up, this proposes the following:
>> >>>
>> >>> 1. Allow PRs on GitHub.
>> >>>
>> >>> 2. Michael Sloan to write a new utility, ghc-hub, which automates
>> tasks interfacing between GitHub and Phab. This utility would be used only
>> by GHC HQ and not by contributors.
>> >>>
>> >>> 3. Small GitHub PRs can be merged directly, by ghc-hub.
>> >>>
>> >>> 4. Larger GitHub PRs can be migrated to Phab by ghc-hub. The
>> contributor would be issued a polite email explaining how to set up a Phab
>> account to continue to follow their contribution.
>> >>>
>> >>> Have I captured this accurately? If so, a resounding +1 from me. I’ve
>> wanted exactly this for a while.
>> >>>
>> >>> Is this worth sending through ghc-proposals?
>> >>>
>> >>> Thanks for volunteering item (2), Michael!
>> >>>
>> >>> Richard
>> >>>
>> >>> -=-=-=-=-=-=-=-=-=-=-
>> >>> Richard A. Eisenberg
>> >>> Asst. Prof. of Computer Science
>> >>> Bryn Mawr College
>> >>> Bryn Mawr, PA, USA
>> >>> cs.brynmawr.edu/~rae
>> >>>
>>  On Sep 26, 2016, at 11:09 PM, Manuel M T Chakravarty <
>> c...@justtesting.org> wrote:
>> 
>>  Sounds like a great idea 

Re: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion

[Eric Seidel]

On Wed, Sep 28, 2016, at 18:37, Ben Gamari wrote:
> Moritz Angermann  writes:
> 
> > All that arc essentially does is, compute the diff from an offset
> > (e.g. master) to the current HEAD and upload that to a new or existing
> > (--update) differential. It also adds some meta information about the
> > range, such that arc patch supposedly knows into which commit to apply
> > the patch to.
> >
> Sure, but this leads to generally unreviewable patches IMHO. In order to
> stay sane I generally split up my work into a set of standalone patches
> with git rebase and then create a Diff of each of these commits.
> Phabricator supports this by having a notion of dependencies between
> Diffs, but arcanist has no sensible scheme for taking a branch and
> conveniently producing a series of Diffs.

I completely understand how this would be frustrating for core
contributors (more specifically for people submitting large patches),
but for new or casual contributors it's actually quite freeing. I don't
have to worry about how messy my local history gets, because arc will
throw it all away regardless! It absolves me of an extra responsibility,
and lowers the barrier to contributing.

It would be nice to support both workflows though :)
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion

[Moritz Angermann]

>> Hence you can go wild on your local branches (use what ever
>> development model suites your needs) and get one final squashed commit
>> with an extensive summary.
>> 
> Sure, but this leads to generally unreviewable patches IMHO. In order to
> stay sane I generally split up my work into a set of standalone patches
> with git rebase and then create a Diff of each of these commits.
> Phabricator supports this by having a notion of dependencies between
> Diffs, but arcanist has no sensible scheme for taking a branch and
> conveniently producing a series of Diffs.

Yes, this has been a constant source of frustration for us as well. Dealing
with dependent diffs is just plain painful with arc :( What I usually end up
doing, and I assume that’s what you are describing is:

Turning

A -- B -- C -- D -- E -- F -- origin/master
^
HEAD

into:

branch B1:  E -- F -- origin/master
  /
branch B2:  C -- D
  /
branch B3: A -- B  

and producing three diffs:

$ git checkout E
$ arc diff origin/master # producing D1

$ git checkout C
$ arc diff B1 # adding “depends on D1" into the summary field

$ git checkout A
$ git diff B2 # adding “depends on D2” into the summary field

and then rebase B2 and B3 when changes to D1 on B1 are necessary.

Running `arc patch` with dependent diffs often resulted in trouble;
this seems to be getting better with the staging areas though.

So clearly we can see there are drawbacks.  All I wanted to say in
the previous email was essentially that from my experience frustration
with arc often came from trying to make arc be git.

Cheers,
 Moritz
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion

[Ben Gamari]

Moritz Angermann  writes:

> I don't think Phabricator tries to be or emulate fit in any way; I
> think this is a misconception. The way I see it, phabricator is just a
> glorified diff-dump, which is supposed to work with any VCS in
> principle.
>
> All that arc essentially does is, compute the diff from an offset
> (e.g. master) to the current HEAD and upload that to a new or existing
> (--update) differential. It also adds some meta information about the
> range, such that arc patch supposedly knows into which commit to apply
> the patch to.
>
> By default arc does not preserve history if memory serves me right but
> uses the summary field exclusively for the commit message.
>
> Hence you can go wild on your local branches (use what ever
> development model suites your needs) and get one final squashed commit
> with an extensive summary.
>
Sure, but this leads to generally unreviewable patches IMHO. In order to
stay sane I generally split up my work into a set of standalone patches
with git rebase and then create a Diff of each of these commits.
Phabricator supports this by having a notion of dependencies between
Diffs, but arcanist has no sensible scheme for taking a branch and
conveniently producing a series of Diffs.

Cheers,

- Ben



signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion

[Moritz Angermann]

I don't think Phabricator tries to be or emulate fit in any way; I think this 
is a misconception. The way I see it, phabricator is just a glorified 
diff-dump, which is supposed to work with any VCS in principle.

All that arc essentially does is, compute the diff from an offset (e.g. master) 
to the current HEAD and upload that to a new or existing (--update) 
differential. It also adds some meta information about the range, such that arc 
patch supposedly knows into which commit to apply the patch to. 

By default arc does not preserve history if memory serves me right but uses the 
summary field exclusively for the commit message.

Hence you can go wild on your local branches (use what ever development model 
suites your needs) and get one final squashed commit with an extensive summary.

In my experience much of the frustration with arc comes from trying to use arc 
as git and grafting a hit workflow onto arc.

To me, git is the organizing (branches and commits) and snapshotting solution 
to keep me sane and allow for experimentations without fear of loosing 
anything. Arc however is the tool that allows me to take my local mess and 
manage it as a reviewable patch I can update from my local tree if need be.

Cheers,
 Moritz


Sent from my iPhone

> On 29 Sep 2016, at 4:03 AM, Michael Sloan  wrote:
> 
>> On Wed, Sep 28, 2016 at 9:06 AM, Ben Gamari  wrote:
>> That being said, I ultimately decided it would be easier to just
>> continue carrying out this workflow by hand considering I don't post
>> large series of patches *that* often. I'm also a bit more eager to
>> squash now than I used to be, in part due to the pain of submitting
>> fine-grained patch sets. On the whole I do wish that Phabricator were
>> more Git-like.
> 
> Indeed, I do not know the details of phab / arc, but when encountering
> them, the workflow seemed unlike ordinary git workflows.  It felt like
> it is working hard to implement an atypical git workflow, and learning
> this new workflow takes work.  From the perspective of a contributor,
> it seemed strange since git's usual workflows are wildly successful
> and popular.  Granted, it is easy for people to screw those up too,
> such as by using "git pull" instead of "git pull --rebase" orso.
> 
> -Michael
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion

[Michael Sloan]

On Wed, Sep 28, 2016 at 9:06 AM, Ben Gamari  wrote:
> That being said, I ultimately decided it would be easier to just
> continue carrying out this workflow by hand considering I don't post
> large series of patches *that* often. I'm also a bit more eager to
> squash now than I used to be, in part due to the pain of submitting
> fine-grained patch sets. On the whole I do wish that Phabricator were
> more Git-like.

Indeed, I do not know the details of phab / arc, but when encountering
them, the workflow seemed unlike ordinary git workflows.  It felt like
it is working hard to implement an atypical git workflow, and learning
this new workflow takes work.  From the perspective of a contributor,
it seemed strange since git's usual workflows are wildly successful
and popular.  Granted, it is easy for people to screw those up too,
such as by using "git pull" instead of "git pull --rebase" orso.

-Michael
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion

[Ben Gamari]

Simon Marlow  writes:

> Well, let's be careful here.  I like the idea, but it's not a complete
> solution for people who don't want to use arc, because you can't revise a
> patch after submission in response to reviews, you would have to open a new
> PR.
>
I have considered building something like this in the past since posting
series of patches via Arc is exceedingly painful. It's not entirely
clear what it would look like, but I was thinking the tool would,

 1. take a branch of commits, for instance,

  A -- B -- C -- D -- E -- F -- origin/master
  ^
  HEAD

 2. allow you to decide how to break it into Diffs. for instance,

  new diff 
  A
  B
  new diff
  C
  D
  E
  new diff
  F

which would produce three diffs:
  * one containing commits A and B
  * one containing commits C, D, and E
  * another containing F

 3. run `arc diff` to upload each Diff to Phabricator, setting up the
appropriate dependency structure between the created Diffs

 4. rewrite history of your branch to add an annotation to the commit
messages saying which diff each belongs to

You are then free to continue modifying and even rebasing your branch
and later the tool can be used to update the diffs from the current
state of your branch. The tool could do this automatically,
reconstructing where each commit belongs from the annotations added
during upload.

That being said, I ultimately decided it would be easier to just
continue carrying out this workflow by hand considering I don't post
large series of patches *that* often. I'm also a bit more eager to
squash now than I used to be, in part due to the pain of submitting
fine-grained patch sets. On the whole I do wish that Phabricator were
more Git-like.

Cheers,

- Ben



signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion

[Simon Marlow]

Well, let's be careful here.  I like the idea, but it's not a complete
solution for people who don't want to use arc, because you can't revise a
patch after submission in response to reviews, you would have to open a new
PR.

Perhaps you could build something that would allow revisions to PRs too...
that would be cool.

Cheers
Simon

On 28 September 2016 at 03:22, Michael Sloan  wrote:

> Exactly!  So we will be using Phabricator for the review process, but
> with the github PRs you can use plain git.  This means that new
> contributors will only need to learn about phabricator, and arc will
> be non-mandatory though probably recommended.
>
> Glad you like the idea :)
>
> -Michael
>
> On Tue, Sep 27, 2016 at 6:47 PM, Richard Eisenberg 
> wrote:
> > So you're suggesting that GitHub would function as a sort of alternate
> front-end to Phab. While I've grown to enjoy Phab quite a bit, I still
> strongly dislike arc, which tries to be too clever for my tastes. Provided
> the integration works smoothly, I quite like this idea.
> >
> > Richard
> >
> >> On Sep 27, 2016, at 5:32 PM, Michael Sloan  wrote:
> >>
> >> You're welcome Richard!  I look forward to helping make it happen.  In
> >> the other thread, Alexander Vershilov mentioned that we might instead
> >> consider the following more straightforward workflow:
> >>
> >> 0) Have a bot that watches github for PRs.
> >> 1) Submit whatever you want to github as a PR.
> >> 2) It will be automatically closed and migrated to Phabricator.  I
> >> would like it to automatically create a Phabricator account if you do
> >> not already have one.  The message from the bot will tell you about
> >> this action, and explain how to log in, perhaps even linking to
> >> resources about Phabricator.
> >>
> >> Is this worth it?  I think it is for the one-off cases.  However, you
> >> will have to be prepared that this means that people won't have
> >> arcanist setup, and therefore are less likely to actually iterate on
> >> their PR.  Perhaps we should extend this to the following:
> >>
> >> 3) Subsequent pushes to the branch for the PR will update the
> >> Phabricator differential as if you had pushed via Arcanist.  I think
> >> with this in place, we would have a fully streamlined system that
> >> allows people to use their familiar GitHub workflows, without needing
> >> to learn Arcanist.  Interactions would then still occur on , of
> >> course.
> >>
> >> This way, GHC HQ doesn't even need to learn to use this new "ghc-hub"
> >> tool!  Could name the bot that, though!
> >>
> >> Thoughts?  I think it would be great for this to be proposed formally
> >> soon so that we can make it happen.  I am eager to be able to use my
> >> normal git workflows, as my little experience with Arcanist induced
> >> some head-scratching.  Not the fault of the tool, just a result of
> >> lack of familiarity.
> >>
> >> -Michael
> >>
> >> On Tue, Sep 27, 2016 at 8:46 AM, Richard Eisenberg 
> wrote:
> >>> To sum up, this proposes the following:
> >>>
> >>> 1. Allow PRs on GitHub.
> >>>
> >>> 2. Michael Sloan to write a new utility, ghc-hub, which automates
> tasks interfacing between GitHub and Phab. This utility would be used only
> by GHC HQ and not by contributors.
> >>>
> >>> 3. Small GitHub PRs can be merged directly, by ghc-hub.
> >>>
> >>> 4. Larger GitHub PRs can be migrated to Phab by ghc-hub. The
> contributor would be issued a polite email explaining how to set up a Phab
> account to continue to follow their contribution.
> >>>
> >>> Have I captured this accurately? If so, a resounding +1 from me. I’ve
> wanted exactly this for a while.
> >>>
> >>> Is this worth sending through ghc-proposals?
> >>>
> >>> Thanks for volunteering item (2), Michael!
> >>>
> >>> Richard
> >>>
> >>> -=-=-=-=-=-=-=-=-=-=-
> >>> Richard A. Eisenberg
> >>> Asst. Prof. of Computer Science
> >>> Bryn Mawr College
> >>> Bryn Mawr, PA, USA
> >>> cs.brynmawr.edu/~rae
> >>>
>  On Sep 26, 2016, at 11:09 PM, Manuel M T Chakravarty <
> c...@justtesting.org> wrote:
> 
>  Sounds like a great idea to me and might alleviate SimonM’s concerns
> about fragmentation of dev attention.
> 
>  Manuel
> 
> > Michael Sloan :
> >
> > Argh, sent too soon.  The first paragraph, revised:
> >
> > This sounds like an ideal solution, Ben!  As has been discussed many
> > times before, GitHub has many users familiar with its interface.  By
> > allowing GitHub PRs, the initial contribution barrier will be
> lowered. If
> > there is an easy and straightforward process for shifting big patches
> > to Phabricator, then people who are regularly contributing via GitHub
> > PRs can be incrementally on-boarded to the Phabricator / Arcanist
> > workflow.
> >
> > On Mon, Sep 26, 2016 at 12:07 PM, Michael Sloan 
> wrote:
> >> This sounds like an ideal solution, Ben!  As has been discussed many
> >> times before, GitHub has many users familiar with its interface.  By
> >

Re: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion

[Michael Sloan]

Exactly!  So we will be using Phabricator for the review process, but
with the github PRs you can use plain git.  This means that new
contributors will only need to learn about phabricator, and arc will
be non-mandatory though probably recommended.

Glad you like the idea :)

-Michael

On Tue, Sep 27, 2016 at 6:47 PM, Richard Eisenberg  wrote:
> So you're suggesting that GitHub would function as a sort of alternate 
> front-end to Phab. While I've grown to enjoy Phab quite a bit, I still 
> strongly dislike arc, which tries to be too clever for my tastes. Provided 
> the integration works smoothly, I quite like this idea.
>
> Richard
>
>> On Sep 27, 2016, at 5:32 PM, Michael Sloan  wrote:
>>
>> You're welcome Richard!  I look forward to helping make it happen.  In
>> the other thread, Alexander Vershilov mentioned that we might instead
>> consider the following more straightforward workflow:
>>
>> 0) Have a bot that watches github for PRs.
>> 1) Submit whatever you want to github as a PR.
>> 2) It will be automatically closed and migrated to Phabricator.  I
>> would like it to automatically create a Phabricator account if you do
>> not already have one.  The message from the bot will tell you about
>> this action, and explain how to log in, perhaps even linking to
>> resources about Phabricator.
>>
>> Is this worth it?  I think it is for the one-off cases.  However, you
>> will have to be prepared that this means that people won't have
>> arcanist setup, and therefore are less likely to actually iterate on
>> their PR.  Perhaps we should extend this to the following:
>>
>> 3) Subsequent pushes to the branch for the PR will update the
>> Phabricator differential as if you had pushed via Arcanist.  I think
>> with this in place, we would have a fully streamlined system that
>> allows people to use their familiar GitHub workflows, without needing
>> to learn Arcanist.  Interactions would then still occur on , of
>> course.
>>
>> This way, GHC HQ doesn't even need to learn to use this new "ghc-hub"
>> tool!  Could name the bot that, though!
>>
>> Thoughts?  I think it would be great for this to be proposed formally
>> soon so that we can make it happen.  I am eager to be able to use my
>> normal git workflows, as my little experience with Arcanist induced
>> some head-scratching.  Not the fault of the tool, just a result of
>> lack of familiarity.
>>
>> -Michael
>>
>> On Tue, Sep 27, 2016 at 8:46 AM, Richard Eisenberg  
>> wrote:
>>> To sum up, this proposes the following:
>>>
>>> 1. Allow PRs on GitHub.
>>>
>>> 2. Michael Sloan to write a new utility, ghc-hub, which automates tasks 
>>> interfacing between GitHub and Phab. This utility would be used only by GHC 
>>> HQ and not by contributors.
>>>
>>> 3. Small GitHub PRs can be merged directly, by ghc-hub.
>>>
>>> 4. Larger GitHub PRs can be migrated to Phab by ghc-hub. The contributor 
>>> would be issued a polite email explaining how to set up a Phab account to 
>>> continue to follow their contribution.
>>>
>>> Have I captured this accurately? If so, a resounding +1 from me. I’ve 
>>> wanted exactly this for a while.
>>>
>>> Is this worth sending through ghc-proposals?
>>>
>>> Thanks for volunteering item (2), Michael!
>>>
>>> Richard
>>>
>>> -=-=-=-=-=-=-=-=-=-=-
>>> Richard A. Eisenberg
>>> Asst. Prof. of Computer Science
>>> Bryn Mawr College
>>> Bryn Mawr, PA, USA
>>> cs.brynmawr.edu/~rae
>>>
 On Sep 26, 2016, at 11:09 PM, Manuel M T Chakravarty 
  wrote:

 Sounds like a great idea to me and might alleviate SimonM’s concerns about 
 fragmentation of dev attention.

 Manuel

> Michael Sloan :
>
> Argh, sent too soon.  The first paragraph, revised:
>
> This sounds like an ideal solution, Ben!  As has been discussed many
> times before, GitHub has many users familiar with its interface.  By
> allowing GitHub PRs, the initial contribution barrier will be lowered. If
> there is an easy and straightforward process for shifting big patches
> to Phabricator, then people who are regularly contributing via GitHub
> PRs can be incrementally on-boarded to the Phabricator / Arcanist
> workflow.
>
> On Mon, Sep 26, 2016 at 12:07 PM, Michael Sloan  wrote:
>> This sounds like an ideal solution, Ben!  As has been discussed many
>> times before, GitHub has many users familiar with its interface.  By
>> allowing GitHub PRs, the initial contribution
>>
>> I think it would be acceptable for larger GitHub PRs to have some
>> automated boilerplate response.  Ideally this would look like:
>>
>> """
>> Thanks for making this patch!  I've turned this into a Phab
>> Differential xxx and closed this PR.  Please create a differential
>> account associated with your email address ..."
>> """
>>
>> The email address can be automatically pulled from commit metadata.
>> If one is absent, then this automated process isn't possible.  If it
>

Re: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion

[Michael Sloan]

On Tue, Sep 27, 2016 at 6:49 PM, Moritz Angermann  wrote:
> Hi,
>
> I think it would be great if this was proposed formally. If we could
> integrate this with the improved ghc development proposal[1], this
> would be great! Or turn it into a separate proposal and remove the
> similar parts from the one mentioned.

Cool!  Should I do the integration?  I wouldn't mind if someone else
took these thoughts and integrated them, though I'd like to see how
they get integrated!

> However, on the topic, I’d like to share a few thoughts:
>
> Do we know how many of these GitHub Pull Requests we will actually
> receive? If we migrate *everything* over to phabricator, isn’t that
> just going to increase complexity for most of the minor pull request?

We don't know how many, hopefully lots, right?

What's the usual complexity for a minor patch to GHC - does it just
skip differential and end up getting committed directly to master?  In
that case, yes this would cause there to be a lot more differentials.
Is that a bad thing?  We could certainly consider something more like
the "ghc-hub" tool I've described elsewhere.  This would give more
direct control of what happens to GitHub PRs, but would also require
manual oversight of incoming GitHub PRs.

> If someone fixes a spelling mistake or adds a short comment to
> explain something in more detail, I see no reason why we need to employ
> any heavy machinery and duplication across different tools. These, so
> I would hope, would be trivially merged by a small team of ghc devs
> watching the GitHub PR, especially if we don’t even know how much PRs
> we will receive through GitHub.
>
> On the other hand, if a PR is non-trivial (yes this is a bit of an
> ambiguous term), I’m in favor of asking the person who issued the PR
> to open an account with Phabricator[2], and run `$ arc diff origin/master`
> on his branch, or let us know that he considers this too much effort
> (and is willing to have someone else take over, should there be interest).

> The reasoning behind this is the following: first of all it’s the persons
> work, and unless someone else is willing to take it through the review
> process, this is going to end up being a dead diff in phabricator which
> adds additional overhead there. If there is not enough interest to follow
> a simple few steps document on how to push a non-trivial patch to
> phabricator, can we expect there to be sufficient interest in actually
> following up on the review process?
>
> I see this more as an onboarding problem than a continuous development
> issue. Those who are in the phabricator workflow, will likely just
> continue using it, no? I certainly would! However I might be browsing
> ghc source on GH just because I don’t have that code locally available
> right now and stumble on a spelling mistake, quickly use the editor
> provided by GH and submit one of these trivial PRs.

Exactly!  GH has great support for creating trivial PRs.  It is also a
workflow people are familiar with.  As soon as you ask people to
install a piece of software and learn to use it (arcanist), there is
immediately a cognitive barrier.  Even if the software is easy to
learn.  I recall being confused about arcanist squashing, for example.
I haven't used it in a long time, so I don't recall details.

I can see the attitude of "Well, if you're hacking on GHC, you are
probably capable of learning some new tools."  This is true, but this
stuff is adding cognitive load atop the existing cognitive load of
creating a patch for GHC.

> Those who haven’t used phabricator yet, but are accustomed to the GH
> PR Flow, would start there and then be gently guided towards using
> phabricator and arc. We can do much better at explaining and showing
> the phabricator and arc workflow.

Yup!  That's how I see this as well.  It is leveraging GH PRs as an
easy way to attract contribution, but also guiding people towards
Phabricator.  As things stand, you need to learn both Phabricator and
Arcanist at the same time.  This way, we can start with onboarding
people with phabricator, and later get them to start using archanist
directly.  Some won't make it to that stage, but it will still be
valuable to get GH PRs from them!

> In essence I’d like us see accepting GH Pull Requests and then do
> more data-driven on-demand incremental improvements, instead of trying
> to go all out with excessive tooling.

This is a wise approach!  I think it makes sense to try the manual
labor version of this process before automating it.  Automation should
be on the minds of those doing the work, though, and they can be
reassured that it will get easier once automation is in place.

> Cheers,
>  Moritz
>
>
> [1]: 
> https://github.com/ghc-megacorp/ghc-proposals/blob/improved-ghc-development/proposals/-improved-ghc-development.rst
> [2]: See the contributing to ghc section in [1].
>> On Sep 28, 2016, at 5:32 AM, Michael Sloan  wrote:
>>
>> You're welcome Richard!  I look forward to helping make it ha

Re: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion

[Moritz Angermann]

Hi,

I think it would be great if this was proposed formally. If we could
integrate this with the improved ghc development proposal[1], this
would be great! Or turn it into a separate proposal and remove the
similar parts from the one mentioned.

However, on the topic, I’d like to share a few thoughts:

Do we know how many of these GitHub Pull Requests we will actually
receive? If we migrate *everything* over to phabricator, isn’t that
just going to increase complexity for most of the minor pull request?

If someone fixes a spelling mistake or adds a short comment to
explain something in more detail, I see no reason why we need to employ
any heavy machinery and duplication across different tools. These, so
I would hope, would be trivially merged by a small team of ghc devs
watching the GitHub PR, especially if we don’t even know how much PRs
we will receive through GitHub.

On the other hand, if a PR is non-trivial (yes this is a bit of an
ambiguous term), I’m in favor of asking the person who issued the PR
to open an account with Phabricator[2], and run `$ arc diff origin/master`
on his branch, or let us know that he considers this too much effort
(and is willing to have someone else take over, should there be interest).

The reasoning behind this is the following: first of all it’s the persons
work, and unless someone else is willing to take it through the review
process, this is going to end up being a dead diff in phabricator which
adds additional overhead there. If there is not enough interest to follow
a simple few steps document on how to push a non-trivial patch to
phabricator, can we expect there to be sufficient interest in actually
following up on the review process?

I see this more as an onboarding problem than a continuous development
issue. Those who are in the phabricator workflow, will likely just
continue using it, no? I certainly would! However I might be browsing
ghc source on GH just because I don’t have that code locally available
right now and stumble on a spelling mistake, quickly use the editor
provided by GH and submit one of these trivial PRs.

Those who haven’t used phabricator yet, but are accustomed to the GH
PR Flow, would start there and then be gently guided towards using
phabricator and arc. We can do much better at explaining and showing
the phabricator and arc workflow.

In essence I’d like us see accepting GH Pull Requests and then do 
more data-driven on-demand incremental improvements, instead of trying
to go all out with excessive tooling.

Cheers,
 Moritz


[1]: 
https://github.com/ghc-megacorp/ghc-proposals/blob/improved-ghc-development/proposals/-improved-ghc-development.rst
[2]: See the contributing to ghc section in [1].
> On Sep 28, 2016, at 5:32 AM, Michael Sloan  wrote:
> 
> You're welcome Richard!  I look forward to helping make it happen.  In
> the other thread, Alexander Vershilov mentioned that we might instead
> consider the following more straightforward workflow:
> 
> 0) Have a bot that watches github for PRs.
> 1) Submit whatever you want to github as a PR.
> 2) It will be automatically closed and migrated to Phabricator.  I
> would like it to automatically create a Phabricator account if you do
> not already have one.  The message from the bot will tell you about
> this action, and explain how to log in, perhaps even linking to
> resources about Phabricator.
> 
> Is this worth it?  I think it is for the one-off cases.  However, you
> will have to be prepared that this means that people won't have
> arcanist setup, and therefore are less likely to actually iterate on
> their PR.  Perhaps we should extend this to the following:
> 
> 3) Subsequent pushes to the branch for the PR will update the
> Phabricator differential as if you had pushed via Arcanist.  I think
> with this in place, we would have a fully streamlined system that
> allows people to use their familiar GitHub workflows, without needing
> to learn Arcanist.  Interactions would then still occur on , of
> course.
> 
> This way, GHC HQ doesn't even need to learn to use this new "ghc-hub"
> tool!  Could name the bot that, though!
> 
> Thoughts?  I think it would be great for this to be proposed formally
> soon so that we can make it happen.  I am eager to be able to use my
> normal git workflows, as my little experience with Arcanist induced
> some head-scratching.  Not the fault of the tool, just a result of
> lack of familiarity.
> 
> -Michael
> 
> On Tue, Sep 27, 2016 at 8:46 AM, Richard Eisenberg  
> wrote:
>> To sum up, this proposes the following:
>> 
>> 1. Allow PRs on GitHub.
>> 
>> 2. Michael Sloan to write a new utility, ghc-hub, which automates tasks 
>> interfacing between GitHub and Phab. This utility would be used only by GHC 
>> HQ and not by contributors.
>> 
>> 3. Small GitHub PRs can be merged directly, by ghc-hub.
>> 
>> 4. Larger GitHub PRs can be migrated to Phab by ghc-hub. The contributor 
>> would be issued a polite email explaining how to set up a Phab account to 

Re: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion

[Richard Eisenberg]

So you're suggesting that GitHub would function as a sort of alternate 
front-end to Phab. While I've grown to enjoy Phab quite a bit, I still strongly 
dislike arc, which tries to be too clever for my tastes. Provided the 
integration works smoothly, I quite like this idea.

Richard

> On Sep 27, 2016, at 5:32 PM, Michael Sloan  wrote:
> 
> You're welcome Richard!  I look forward to helping make it happen.  In
> the other thread, Alexander Vershilov mentioned that we might instead
> consider the following more straightforward workflow:
> 
> 0) Have a bot that watches github for PRs.
> 1) Submit whatever you want to github as a PR.
> 2) It will be automatically closed and migrated to Phabricator.  I
> would like it to automatically create a Phabricator account if you do
> not already have one.  The message from the bot will tell you about
> this action, and explain how to log in, perhaps even linking to
> resources about Phabricator.
> 
> Is this worth it?  I think it is for the one-off cases.  However, you
> will have to be prepared that this means that people won't have
> arcanist setup, and therefore are less likely to actually iterate on
> their PR.  Perhaps we should extend this to the following:
> 
> 3) Subsequent pushes to the branch for the PR will update the
> Phabricator differential as if you had pushed via Arcanist.  I think
> with this in place, we would have a fully streamlined system that
> allows people to use their familiar GitHub workflows, without needing
> to learn Arcanist.  Interactions would then still occur on , of
> course.
> 
> This way, GHC HQ doesn't even need to learn to use this new "ghc-hub"
> tool!  Could name the bot that, though!
> 
> Thoughts?  I think it would be great for this to be proposed formally
> soon so that we can make it happen.  I am eager to be able to use my
> normal git workflows, as my little experience with Arcanist induced
> some head-scratching.  Not the fault of the tool, just a result of
> lack of familiarity.
> 
> -Michael
> 
> On Tue, Sep 27, 2016 at 8:46 AM, Richard Eisenberg  
> wrote:
>> To sum up, this proposes the following:
>> 
>> 1. Allow PRs on GitHub.
>> 
>> 2. Michael Sloan to write a new utility, ghc-hub, which automates tasks 
>> interfacing between GitHub and Phab. This utility would be used only by GHC 
>> HQ and not by contributors.
>> 
>> 3. Small GitHub PRs can be merged directly, by ghc-hub.
>> 
>> 4. Larger GitHub PRs can be migrated to Phab by ghc-hub. The contributor 
>> would be issued a polite email explaining how to set up a Phab account to 
>> continue to follow their contribution.
>> 
>> Have I captured this accurately? If so, a resounding +1 from me. I’ve wanted 
>> exactly this for a while.
>> 
>> Is this worth sending through ghc-proposals?
>> 
>> Thanks for volunteering item (2), Michael!
>> 
>> Richard
>> 
>> -=-=-=-=-=-=-=-=-=-=-
>> Richard A. Eisenberg
>> Asst. Prof. of Computer Science
>> Bryn Mawr College
>> Bryn Mawr, PA, USA
>> cs.brynmawr.edu/~rae
>> 
>>> On Sep 26, 2016, at 11:09 PM, Manuel M T Chakravarty  
>>> wrote:
>>> 
>>> Sounds like a great idea to me and might alleviate SimonM’s concerns about 
>>> fragmentation of dev attention.
>>> 
>>> Manuel
>>> 
 Michael Sloan :
 
 Argh, sent too soon.  The first paragraph, revised:
 
 This sounds like an ideal solution, Ben!  As has been discussed many
 times before, GitHub has many users familiar with its interface.  By
 allowing GitHub PRs, the initial contribution barrier will be lowered. If
 there is an easy and straightforward process for shifting big patches
 to Phabricator, then people who are regularly contributing via GitHub
 PRs can be incrementally on-boarded to the Phabricator / Arcanist
 workflow.
 
 On Mon, Sep 26, 2016 at 12:07 PM, Michael Sloan  wrote:
> This sounds like an ideal solution, Ben!  As has been discussed many
> times before, GitHub has many users familiar with its interface.  By
> allowing GitHub PRs, the initial contribution
> 
> I think it would be acceptable for larger GitHub PRs to have some
> automated boilerplate response.  Ideally this would look like:
> 
> """
> Thanks for making this patch!  I've turned this into a Phab
> Differential xxx and closed this PR.  Please create a differential
> account associated with your email address ..."
> """
> 
> The email address can be automatically pulled from commit metadata.
> If one is absent, then this automated process isn't possible.  If it
> is present and
> 
> So, I'm imagining a utility that interfaces between both GitHub and
> Phab,allowing the following commands:
> 
> * "ghc-hub migrate https://github.com/ghc/ghc/pull/1"; - migrates the
> patch to differential.  It may attempt to migrate body and title of
> the initial post, but lets not bother with migrating any review data.
> 
> * "ghc-hub merge https://github.com/ghc/ghc/pull/

Re: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion

[Michael Sloan]

You're welcome Richard!  I look forward to helping make it happen.  In
the other thread, Alexander Vershilov mentioned that we might instead
consider the following more straightforward workflow:

0) Have a bot that watches github for PRs.
1) Submit whatever you want to github as a PR.
2) It will be automatically closed and migrated to Phabricator.  I
would like it to automatically create a Phabricator account if you do
not already have one.  The message from the bot will tell you about
this action, and explain how to log in, perhaps even linking to
resources about Phabricator.

Is this worth it?  I think it is for the one-off cases.  However, you
will have to be prepared that this means that people won't have
arcanist setup, and therefore are less likely to actually iterate on
their PR.  Perhaps we should extend this to the following:

3) Subsequent pushes to the branch for the PR will update the
Phabricator differential as if you had pushed via Arcanist.  I think
with this in place, we would have a fully streamlined system that
allows people to use their familiar GitHub workflows, without needing
to learn Arcanist.  Interactions would then still occur on , of
course.

This way, GHC HQ doesn't even need to learn to use this new "ghc-hub"
tool!  Could name the bot that, though!

Thoughts?  I think it would be great for this to be proposed formally
soon so that we can make it happen.  I am eager to be able to use my
normal git workflows, as my little experience with Arcanist induced
some head-scratching.  Not the fault of the tool, just a result of
lack of familiarity.

-Michael

On Tue, Sep 27, 2016 at 8:46 AM, Richard Eisenberg  wrote:
> To sum up, this proposes the following:
>
> 1. Allow PRs on GitHub.
>
> 2. Michael Sloan to write a new utility, ghc-hub, which automates tasks 
> interfacing between GitHub and Phab. This utility would be used only by GHC 
> HQ and not by contributors.
>
> 3. Small GitHub PRs can be merged directly, by ghc-hub.
>
> 4. Larger GitHub PRs can be migrated to Phab by ghc-hub. The contributor 
> would be issued a polite email explaining how to set up a Phab account to 
> continue to follow their contribution.
>
> Have I captured this accurately? If so, a resounding +1 from me. I’ve wanted 
> exactly this for a while.
>
> Is this worth sending through ghc-proposals?
>
> Thanks for volunteering item (2), Michael!
>
> Richard
>
> -=-=-=-=-=-=-=-=-=-=-
> Richard A. Eisenberg
> Asst. Prof. of Computer Science
> Bryn Mawr College
> Bryn Mawr, PA, USA
> cs.brynmawr.edu/~rae
>
>> On Sep 26, 2016, at 11:09 PM, Manuel M T Chakravarty  
>> wrote:
>>
>> Sounds like a great idea to me and might alleviate SimonM’s concerns about 
>> fragmentation of dev attention.
>>
>> Manuel
>>
>>> Michael Sloan :
>>>
>>> Argh, sent too soon.  The first paragraph, revised:
>>>
>>> This sounds like an ideal solution, Ben!  As has been discussed many
>>> times before, GitHub has many users familiar with its interface.  By
>>> allowing GitHub PRs, the initial contribution barrier will be lowered. If
>>> there is an easy and straightforward process for shifting big patches
>>> to Phabricator, then people who are regularly contributing via GitHub
>>> PRs can be incrementally on-boarded to the Phabricator / Arcanist
>>> workflow.
>>>
>>> On Mon, Sep 26, 2016 at 12:07 PM, Michael Sloan  wrote:
 This sounds like an ideal solution, Ben!  As has been discussed many
 times before, GitHub has many users familiar with its interface.  By
 allowing GitHub PRs, the initial contribution

 I think it would be acceptable for larger GitHub PRs to have some
 automated boilerplate response.  Ideally this would look like:

 """
 Thanks for making this patch!  I've turned this into a Phab
 Differential xxx and closed this PR.  Please create a differential
 account associated with your email address ..."
 """

 The email address can be automatically pulled from commit metadata.
 If one is absent, then this automated process isn't possible.  If it
 is present and

 So, I'm imagining a utility that interfaces between both GitHub and
 Phab,allowing the following commands:

 * "ghc-hub migrate https://github.com/ghc/ghc/pull/1"; - migrates the
 patch to differential.  It may attempt to migrate body and title of
 the initial post, but lets not bother with migrating any review data.

 * "ghc-hub merge https://github.com/ghc/ghc/pull/1"; - merges the
 patch.  This is used for merging small patches.  It would not do an
 automated push.  Maybe have "--push" also perform the push?  So like
 if you are on master, then "ghc-hub merge
 https://github.com/ghc/ghc/pull/1 --push" would merge the patches and
 push to master.

 How does this sound?  I like the idea a lot, and would enjoy helping
 with implementation, time permitting.  I could possibly start hacking
 on it if others give the go ahead of "Yes, lets d

Re: Notes from Ben's "contribute to ghc" discussion

[Michael Sloan]

On Tue, Sep 27, 2016 at 8:20 AM, Alexander V Vershilov
 wrote:
>
> About GitHub based contribution. It looks great for me for *all
> types* of the patches. But.. bot (or for some time person) should
> migrate *all* the patches to Phab, closing the threads for comments.
> Bot should write some welcome message than with a link to Phab
> request and intruction how to allow Phab to use github account
> and read email if there is no account yet.
> This way when review had happened author will automatically receive
> all review comments with links to Phab, I'll hardly get that following
> a link to github is any harder than following link to Phab (assuming
> Phab  to login using github account). If user addressed comment
> he should be able to just force-push/update his branch and new revision
> should be created by bot. PR on github should be closed whenever Phab
> request will be closed, so it would be trackable using GitHub only.

I think this could make a great deal of sense.  This will allow us to
use the familiar GitHub interface for creating PRs, but all PRs will
be maintained within phabricator.

Creating a PR should automatically cause the user to create an account
on Phabricator, if possible.

I've done a quick search to see if a tool exists for this, and all I
found was this abandoned patch in the phabricator project itself.
https://secure.phabricator.com/D8775

Unfortunately (or fortunately, hah!), I do not know PHP.  However, if
phabricator has a RESTful API it seems imminently feasible to
implement this as a bot written in Haskell.

> This way github-ish users could use tool that they used to, but also
> reviewers to use the tool they also used to. All the review
> comments will be stored in the single place, no revisions will be lost.
> This way could be automated and there will be no strange questions
> about what is large patch and what is not. The only people who use
> are ones that doesn't use email to receive review comments and can
> use only GitHub interface to read that, but I doubt that such users exists.
>
> --
> Alexander
>
> On 24 September 2016 at 04:44, Simon Peyton Jones via ghc-devs
>  wrote:
>> Friends
>>
>>
>>
>> Here are the notes I took from session 2 of the Haskell Implementors
>> Meeting.  The bolding is my choice of emphasis.
>>
>>
>>
>> Simon
>>
>>
>>
>> ·Doc bugs.Two kinds
>>
>> o   Typos.   Friction stops me
>>
>> o   Explanations needed e.g. read/show
>>
>> ·Lightweight pushes
>>
>> ·Make user manual into its own repo, to make it easier to take pull
>> requests.  But that makes it harder when making synchronised changes to GHC
>> and user manual.
>>
>> ·Auto-push: Ability to push to Phab and have it committed
>> automatically if it validates.
>>
>> ·Style guides.  Is having a defined style solving a problem we don’t
>> really have?  One piece of guidance: adhere to the style of the surrounding
>> code.  Low priority.
>>
>> ·Docker images.   We should have one.
>>
>> ·Remove old documentation!
>>
>> ·Cross compilation is difficult.
>>
>> ·Have a GHC StackOverflow on haskell.org   (Jacob Zalewski
>> jakz...@gmail.com offers to do this! – thank you).  It has a useful new
>> Documentation feature.   Eg this would be good for “how do I look up a
>> RdrName to get a Name… there seem to be six different functions that do
>> that”.
>>
>>
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>
>
>
> --
> Alexander
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion

[Richard Eisenberg]

To sum up, this proposes the following:

1. Allow PRs on GitHub.

2. Michael Sloan to write a new utility, ghc-hub, which automates tasks 
interfacing between GitHub and Phab. This utility would be used only by GHC HQ 
and not by contributors.

3. Small GitHub PRs can be merged directly, by ghc-hub.

4. Larger GitHub PRs can be migrated to Phab by ghc-hub. The contributor would 
be issued a polite email explaining how to set up a Phab account to continue to 
follow their contribution.

Have I captured this accurately? If so, a resounding +1 from me. I’ve wanted 
exactly this for a while.

Is this worth sending through ghc-proposals?

Thanks for volunteering item (2), Michael!

Richard

-=-=-=-=-=-=-=-=-=-=-
Richard A. Eisenberg
Asst. Prof. of Computer Science
Bryn Mawr College
Bryn Mawr, PA, USA
cs.brynmawr.edu/~rae

> On Sep 26, 2016, at 11:09 PM, Manuel M T Chakravarty  
> wrote:
> 
> Sounds like a great idea to me and might alleviate SimonM’s concerns about 
> fragmentation of dev attention.
> 
> Manuel
> 
>> Michael Sloan :
>> 
>> Argh, sent too soon.  The first paragraph, revised:
>> 
>> This sounds like an ideal solution, Ben!  As has been discussed many
>> times before, GitHub has many users familiar with its interface.  By
>> allowing GitHub PRs, the initial contribution barrier will be lowered. If
>> there is an easy and straightforward process for shifting big patches
>> to Phabricator, then people who are regularly contributing via GitHub
>> PRs can be incrementally on-boarded to the Phabricator / Arcanist
>> workflow.
>> 
>> On Mon, Sep 26, 2016 at 12:07 PM, Michael Sloan  wrote:
>>> This sounds like an ideal solution, Ben!  As has been discussed many
>>> times before, GitHub has many users familiar with its interface.  By
>>> allowing GitHub PRs, the initial contribution
>>> 
>>> I think it would be acceptable for larger GitHub PRs to have some
>>> automated boilerplate response.  Ideally this would look like:
>>> 
>>> """
>>> Thanks for making this patch!  I've turned this into a Phab
>>> Differential xxx and closed this PR.  Please create a differential
>>> account associated with your email address ..."
>>> """
>>> 
>>> The email address can be automatically pulled from commit metadata.
>>> If one is absent, then this automated process isn't possible.  If it
>>> is present and
>>> 
>>> So, I'm imagining a utility that interfaces between both GitHub and
>>> Phab,allowing the following commands:
>>> 
>>> * "ghc-hub migrate https://github.com/ghc/ghc/pull/1"; - migrates the
>>> patch to differential.  It may attempt to migrate body and title of
>>> the initial post, but lets not bother with migrating any review data.
>>> 
>>> * "ghc-hub merge https://github.com/ghc/ghc/pull/1"; - merges the
>>> patch.  This is used for merging small patches.  It would not do an
>>> automated push.  Maybe have "--push" also perform the push?  So like
>>> if you are on master, then "ghc-hub merge
>>> https://github.com/ghc/ghc/pull/1 --push" would merge the patches and
>>> push to master.
>>> 
>>> How does this sound?  I like the idea a lot, and would enjoy helping
>>> with implementation, time permitting.  I could possibly start hacking
>>> on it if others give the go ahead of "Yes, lets do that".
>>> 
>>> -Michael
>>> 
>>> On Mon, Sep 26, 2016 at 11:45 AM, Ben Gamari  wrote:
 Carter Schonwald  writes:
 
> In writing the following huge wall of text, I had and idea that I think
> many folks would find palatable:
> 
> What if simple small patches (such as hypothetical drive by doc patches )
> had a mailing list where folks could email the simple / small patches as
> email attachments plus a body text that summarizes the patch, what it 
> does,
> and why it's simple!
> 
 I completely agree that for small (e.g. documentation) patches our
 current system is quite heavy. For this reason I suggested at ICFP that
 we simply begin accepting small patches via GitHub pull requests.
 Frankly, this is less work for me than merging patches from a mailing
 list and I believe many users feel that GitHub is more accessible than a
 mailing list.
 
 The problem of course is what subset of patches do we want to allow to
 be taken via GitHub. My suggested answer to that is any patch which, if
 I were to write it myself, I would feel comfortable pushing directly to
 the tree.
 
 Then there is the question of what do we do with pull requests opened
 which do not satisfy this criterion. In this case I would likely open a
 Phabricator Differential with the pull request and close the pull
 request with a link to the Diff. In the ideal case this will inspire the
 contributor to join the review process on Phabricator; in the worst case
 review turns up issues in the patch and the user gives up. Either way, at
 least the contributor feels his patch has been seen and given the
 attention it deserves.
 
 Cheers,

Re: Notes from Ben's "contribute to ghc" discussion

[Alexander V Vershilov]

I think I'm a bit late for the party.

I'm speaking with the newcomer hat on, as basically I have
contributed only few trivial patches. So not sure if my experience
matter.

Originally I was submitting patches using Trac, but then was kindly
asked (IIRC by Simon Marlow) to use Phab instead. Surprisingly enough
I had no problems with Phab, and setup took about 15 minutes
(most of that time I spend on php compilation). Student that I used
to co-mentor this year on HSoC also said that he had zero problems
with Phab and that it took 5 minutes to set everything up. So from
my personal point of view problem of the Phabricator are heavily
overrated.

Whenever you do non trivial (not simple documentation fix) amount
of work and documentation needs to be read highly preside the
complexity of the work for submitting patch. Review requests and
email that is sent is greatly structured, latest changes on  github
makes small step toward but anyway not that good. Also for almost
all the changes I had to contact #ghc or persons who is familiar with
that subsystem and always had great and prompt feedback.

What I'm written above doesn't mean that it's nowhere to improve.
Documentation on the wiki may be structured better and sometimes
it's very hard to get the actual state by reading it. Especially if there
was some ongoing discussion without highlighting the outcome.

As many already highlighted in this thread having a single account for
trac, phab and ideally popular system people people already use will be
beneficial.  Without that I think other improvements will not work well.

Also it would be nice if it was possible to automate some actions like
adding a link from trac to Phab. I remember spending much time on
trying to recall correct syntax to add link to Phab.

About GitHub based contribution. It looks great for me for *all
types* of the patches. But.. bot (or for some time person) should
migrate *all* the patches to Phab, closing the threads for comments.
Bot should write some welcome message than with a link to Phab
request and intruction how to allow Phab to use github account
and read email if there is no account yet.
This way when review had happened author will automatically receive
all review comments with links to Phab, I'll hardly get that following
a link to github is any harder than following link to Phab (assuming
Phab  to login using github account). If user addressed comment
he should be able to just force-push/update his branch and new revision
should be created by bot. PR on github should be closed whenever Phab
request will be closed, so it would be trackable using GitHub only.

This way github-ish users could use tool that they used to, but also
reviewers to use the tool they also used to. All the review
comments will be stored in the single place, no revisions will be lost.
This way could be automated and there will be no strange questions
about what is large patch and what is not. The only people who use
are ones that doesn't use email to receive review comments and can
use only GitHub interface to read that, but I doubt that such users exists.

--
Alexander

On 24 September 2016 at 04:44, Simon Peyton Jones via ghc-devs
 wrote:
> Friends
>
>
>
> Here are the notes I took from session 2 of the Haskell Implementors
> Meeting.  The bolding is my choice of emphasis.
>
>
>
> Simon
>
>
>
> ·Doc bugs.Two kinds
>
> o   Typos.   Friction stops me
>
> o   Explanations needed e.g. read/show
>
> ·Lightweight pushes
>
> ·Make user manual into its own repo, to make it easier to take pull
> requests.  But that makes it harder when making synchronised changes to GHC
> and user manual.
>
> ·Auto-push: Ability to push to Phab and have it committed
> automatically if it validates.
>
> ·Style guides.  Is having a defined style solving a problem we don’t
> really have?  One piece of guidance: adhere to the style of the surrounding
> code.  Low priority.
>
> ·Docker images.   We should have one.
>
> ·Remove old documentation!
>
> ·Cross compilation is difficult.
>
> ·Have a GHC StackOverflow on haskell.org   (Jacob Zalewski
> jakz...@gmail.com offers to do this! – thank you).  It has a useful new
> Documentation feature.   Eg this would be good for “how do I look up a
> RdrName to get a Name… there seem to be six different functions that do
> that”.
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>



-- 
Alexander
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Notes from Ben's "contribute to ghc" discussion

[Simon Peyton Jones via ghc-devs]

Friends

Wow!  I didn't expect my scrappy notes to generate so much traffic!

Some quick thoughts:

* My notes were typed in real-time, during an open 70-person
  discussion during the Haskell Implementors Workshop.  Air-time was
  limited, and I just wanted to capture suggestions that people made.
  They do not reflect a thoughtful agreement or a concrete plan.

* As it happens, some of the subsequent traffic illustrates rather
  well the challenges that I wanted to address in my "Respect" post to
  haskell.org, although I posted the latter before seeing the former.

  The good thing is that we ALL share the same goals: to make it as
  easy as possible for both newcomers and hard-core developers to
  contribute to GHC; to preserve GHC's conceptual integrity; to
  operate within the limits of what a bunch of volunteers can do.  We
  may differ in our judgements about how best to achieve those goals,
  but I'm certain that, if we take a little care, we can do so in the
  language of colleagues not adversaries.

  Happily, everything has calmed down a bit now, but still I'd like
  to renew my plea for courtesy; and in particular, to start from an
  assumption of good faith.  Nobody here is seeking to be hostile,
  dismissive, or excluding.  If my behaviour appears to you to be any
  of those things, please talk me privately, not in public; I have
  probably just failed to express myself well.

* Turning to the main issue of substance -- reducing the barrier to
  entry for new contributors -- one plea is "Just do it on Github, the
  same as everyone else".  I can see the force of that argument;
  Chris Allen calls it "legibility": simply being similar to other
  workflows reduces the barrier to entry.  (Chris and I had a useful
  conversation last night; thanks Chris.)

  I do not have a well-informed opinion about whether Github can do
  the job for us -- it's not the same Github as when we last
  consciously decided not to go that route.  Even if we stick with
  Phab we could probably do a better job of explaining the workflow,
  so that someone new is in no doubt about how to contribute.  But the
  choice of technology is, in the end, a judgement call about the
  balance of plusses and minuses.

* I really like Jakub Zalewski's suggestion of having a GHC-specific
  StackOverflow instance.  StackOverflow seems to have captured a
  great way for people to have a technical questions and answers.
  That might be better than the GHC wiki, or at least a great
  complement to it.  Better still, Jakub has volunteered to spin one
  up, an offer I think we should grab with both hands.

* I'm open to the idea of mentors -- if we could find enough people
  willing to act as mentors. I'm not confident we have enough supply
  to meet the demand, but perhaps we should try and see?
  
* It's worth remembering that we are in the midst of revising the
  process of how to propose a change to GHC, and the language it
  compiles, in direct response to feedback from the GHC developer
  community.

Onward and upward

Simon
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Notes from Ben's "contribute to ghc" discussion

[Simon Marlow]

On 26 September 2016 at 22:51, Ben Gamari  wrote:

> Simon Marlow  writes:
>
> > But this is opening the floodgates a crack... how do we know what a
> "small"
> > patch is?  What happens when someone submits a patch that's too large?
> >
> I tried to address these questions in the "Create a
> ghc-simple-patch-propose list?" thread where I said,
>
> Ben Gamari  writes:
>
> > I completely agree that for small (e.g. documentation) patches our
> > current system is quite heavy. For this reason I suggested at ICFP that
> > we simply begin accepting small patches via GitHub pull requests.
> > Frankly, this is less work for me than merging patches from a mailing
> > list and I believe many users feel that GitHub is more accessible than a
> > mailing list.
> >
> > The problem of course is what subset of patches do we want to allow to
> > be taken via GitHub. My suggested answer to that is any patch which, if
> > I were to write it myself, I would feel comfortable pushing directly to
> > the tree.
> >
> > Then there is the question of what do we do with pull requests opened
> > which do not satisfy this criterion. In this case I would likely open a
> > Phabricator Differential with the pull request and close the pull
> > request with a link to the Diff. In the ideal case this will inspire the
> > contributor to join the review process on Phabricator; in the worst case
> > review turns up issues in the patch and the user gives up. Either way, at
> > least the contributor feels his patch has been seen and given the
> > attention it deserves.
>
> Does this help?
>

Well ok.  I'm still concerned that adding a new contribution method is not
making things simpler, and that we have even more process and things to
document, which might itself be discouraging to new users.  But if you say
it's easy for you to accept patches this way, and that the rest of us can
mostly ignore github then I guess that limits the downsides.

Of course if people say this is what they actually want, then who am I to
disagree :)

Cheers
Simon



>
>
> Simon Marlow  writes:
>
> > The patches will get larger, we'll have to do code reviews on two
> > different tools, and it will be really hard to go back. I just have a
> > bad feeling about this.
> >
> I share your worry that the GitHub patch sizes will "creep". That being
> said, I think that as long as we can easily move to Phabricator for
> reviewing larger patches it will be manageable.
>
> Moreover, I suspect that once someone has submitted a patch via GitHub,
> the effort that they have sunk into it will mean that they will be more
> likely to follow the patch to Phabricator to participate in review (and
> hopefully revision) if we move it.
>
> >> It does certainly put yet another task on our plates, but I would argue
> >> that it's actually easier than accepting patches via Trac, which we
> >> already do.
> >
> > We should stop accepting patches via Trac too :)
> >
> Heh, it would certainly make my life easier. That being said, there
> (thankfully) aren't too many that come in via this channel at this
> point.
>
> Cheers,
>
> - Ben
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion

[Manuel M T Chakravarty]

Sounds like a great idea to me and might alleviate SimonM’s concerns about 
fragmentation of dev attention.

Manuel

> Michael Sloan :
> 
> Argh, sent too soon.  The first paragraph, revised:
> 
> This sounds like an ideal solution, Ben!  As has been discussed many
> times before, GitHub has many users familiar with its interface.  By
> allowing GitHub PRs, the initial contribution barrier will be lowered. If
> there is an easy and straightforward process for shifting big patches
> to Phabricator, then people who are regularly contributing via GitHub
> PRs can be incrementally on-boarded to the Phabricator / Arcanist
> workflow.
> 
> On Mon, Sep 26, 2016 at 12:07 PM, Michael Sloan  wrote:
>> This sounds like an ideal solution, Ben!  As has been discussed many
>> times before, GitHub has many users familiar with its interface.  By
>> allowing GitHub PRs, the initial contribution
>> 
>> I think it would be acceptable for larger GitHub PRs to have some
>> automated boilerplate response.  Ideally this would look like:
>> 
>> """
>> Thanks for making this patch!  I've turned this into a Phab
>> Differential xxx and closed this PR.  Please create a differential
>> account associated with your email address ..."
>> """
>> 
>> The email address can be automatically pulled from commit metadata.
>> If one is absent, then this automated process isn't possible.  If it
>> is present and
>> 
>> So, I'm imagining a utility that interfaces between both GitHub and
>> Phab,allowing the following commands:
>> 
>> * "ghc-hub migrate https://github.com/ghc/ghc/pull/1"; - migrates the
>> patch to differential.  It may attempt to migrate body and title of
>> the initial post, but lets not bother with migrating any review data.
>> 
>> * "ghc-hub merge https://github.com/ghc/ghc/pull/1"; - merges the
>> patch.  This is used for merging small patches.  It would not do an
>> automated push.  Maybe have "--push" also perform the push?  So like
>> if you are on master, then "ghc-hub merge
>> https://github.com/ghc/ghc/pull/1 --push" would merge the patches and
>> push to master.
>> 
>> How does this sound?  I like the idea a lot, and would enjoy helping
>> with implementation, time permitting.  I could possibly start hacking
>> on it if others give the go ahead of "Yes, lets do that".
>> 
>> -Michael
>> 
>> On Mon, Sep 26, 2016 at 11:45 AM, Ben Gamari  wrote:
>>> Carter Schonwald  writes:
>>> 
 In writing the following huge wall of text, I had and idea that I think
 many folks would find palatable:
 
 What if simple small patches (such as hypothetical drive by doc patches )
 had a mailing list where folks could email the simple / small patches as
 email attachments plus a body text that summarizes the patch, what it does,
 and why it's simple!
 
>>> I completely agree that for small (e.g. documentation) patches our
>>> current system is quite heavy. For this reason I suggested at ICFP that
>>> we simply begin accepting small patches via GitHub pull requests.
>>> Frankly, this is less work for me than merging patches from a mailing
>>> list and I believe many users feel that GitHub is more accessible than a
>>> mailing list.
>>> 
>>> The problem of course is what subset of patches do we want to allow to
>>> be taken via GitHub. My suggested answer to that is any patch which, if
>>> I were to write it myself, I would feel comfortable pushing directly to
>>> the tree.
>>> 
>>> Then there is the question of what do we do with pull requests opened
>>> which do not satisfy this criterion. In this case I would likely open a
>>> Phabricator Differential with the pull request and close the pull
>>> request with a link to the Diff. In the ideal case this will inspire the
>>> contributor to join the review process on Phabricator; in the worst case
>>> review turns up issues in the patch and the user gives up. Either way, at
>>> least the contributor feels his patch has been seen and given the
>>> attention it deserves.
>>> 
>>> Cheers,
>>> 
>>> - Ben
>>> 
>>> ___
>>> ghc-devs mailing list
>>> ghc-devs@haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>> 
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Notes from Ben's "contribute to ghc" discussion

[Richard Fung]

>
> That is a great point; it's easy for me to forget how I felt when I was
> a beginner. I've added a brief paragraph to the Newcomers page,
> If you have any questions along the way don't hesitate to reach out
> to the community. There are people on the mailing lists and IRC who
> will gladly help you (although you may need to be patient). Don't
> forget that all GHC developers are still learning; your question is
> never too silly to ask.
> Can you see any way this could be improved?



> That is a fair point; I've added some language to the Newcomers page
> encouraging these sorts of inqueries,
> == Finding a ticket ==
> Now that you can build GHC, let's get hacking. But first, you'll
> need to identify a goal. GHC's Trac tickets are a great place to
> find starting points. You are encouraged to ask for a starting point
> on IRC or the ghc-devs mailing list. There someone familiar with the
> process can help you find a ticket that matches your expertise and
> help you when troubles arise.
> If you want to get a taste for possible starting tasks, below is a
> list of tickets that appear to be "low-hanging fruit" -- things that
> might be reasonable for a newcomer to GHC hacking. Of course, we
> can't ever be sure of how hard a task is before doing it, so
> apologies if one of these is too hard.
> Is this better?


I think both of these are great. Thanks!

On Mon, Sep 26, 2016 at 2:51 PM, Ben Gamari  wrote:

> Simon Marlow  writes:
>
> > But this is opening the floodgates a crack... how do we know what a
> "small"
> > patch is?  What happens when someone submits a patch that's too large?
> >
> I tried to address these questions in the "Create a
> ghc-simple-patch-propose list?" thread where I said,
>
> Ben Gamari  writes:
>
> > I completely agree that for small (e.g. documentation) patches our
> > current system is quite heavy. For this reason I suggested at ICFP that
> > we simply begin accepting small patches via GitHub pull requests.
> > Frankly, this is less work for me than merging patches from a mailing
> > list and I believe many users feel that GitHub is more accessible than a
> > mailing list.
> >
> > The problem of course is what subset of patches do we want to allow to
> > be taken via GitHub. My suggested answer to that is any patch which, if
> > I were to write it myself, I would feel comfortable pushing directly to
> > the tree.
> >
> > Then there is the question of what do we do with pull requests opened
> > which do not satisfy this criterion. In this case I would likely open a
> > Phabricator Differential with the pull request and close the pull
> > request with a link to the Diff. In the ideal case this will inspire the
> > contributor to join the review process on Phabricator; in the worst case
> > review turns up issues in the patch and the user gives up. Either way, at
> > least the contributor feels his patch has been seen and given the
> > attention it deserves.
>
> Does this help?
>
>
> Simon Marlow  writes:
>
> > The patches will get larger, we'll have to do code reviews on two
> > different tools, and it will be really hard to go back. I just have a
> > bad feeling about this.
> >
> I share your worry that the GitHub patch sizes will "creep". That being
> said, I think that as long as we can easily move to Phabricator for
> reviewing larger patches it will be manageable.
>
> Moreover, I suspect that once someone has submitted a patch via GitHub,
> the effort that they have sunk into it will mean that they will be more
> likely to follow the patch to Phabricator to participate in review (and
> hopefully revision) if we move it.
>
> >> It does certainly put yet another task on our plates, but I would argue
> >> that it's actually easier than accepting patches via Trac, which we
> >> already do.
> >
> > We should stop accepting patches via Trac too :)
> >
> Heh, it would certainly make my life easier. That being said, there
> (thankfully) aren't too many that come in via this channel at this
> point.
>
> Cheers,
>
> - Ben
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Notes from Ben's "contribute to ghc" discussion

[Ben Gamari]

Simon Marlow  writes:

> But this is opening the floodgates a crack... how do we know what a "small"
> patch is?  What happens when someone submits a patch that's too large?
>
I tried to address these questions in the "Create a
ghc-simple-patch-propose list?" thread where I said,

Ben Gamari  writes:

> I completely agree that for small (e.g. documentation) patches our
> current system is quite heavy. For this reason I suggested at ICFP that
> we simply begin accepting small patches via GitHub pull requests.
> Frankly, this is less work for me than merging patches from a mailing
> list and I believe many users feel that GitHub is more accessible than a
> mailing list.
>
> The problem of course is what subset of patches do we want to allow to
> be taken via GitHub. My suggested answer to that is any patch which, if
> I were to write it myself, I would feel comfortable pushing directly to
> the tree.
>
> Then there is the question of what do we do with pull requests opened
> which do not satisfy this criterion. In this case I would likely open a
> Phabricator Differential with the pull request and close the pull
> request with a link to the Diff. In the ideal case this will inspire the
> contributor to join the review process on Phabricator; in the worst case
> review turns up issues in the patch and the user gives up. Either way, at
> least the contributor feels his patch has been seen and given the
> attention it deserves.

Does this help?


Simon Marlow  writes:

> The patches will get larger, we'll have to do code reviews on two
> different tools, and it will be really hard to go back. I just have a
> bad feeling about this.
>
I share your worry that the GitHub patch sizes will "creep". That being
said, I think that as long as we can easily move to Phabricator for
reviewing larger patches it will be manageable.

Moreover, I suspect that once someone has submitted a patch via GitHub,
the effort that they have sunk into it will mean that they will be more
likely to follow the patch to Phabricator to participate in review (and
hopefully revision) if we move it.

>> It does certainly put yet another task on our plates, but I would argue
>> that it's actually easier than accepting patches via Trac, which we
>> already do.
>
> We should stop accepting patches via Trac too :)
>
Heh, it would certainly make my life easier. That being said, there
(thankfully) aren't too many that come in via this channel at this
point.

Cheers,

- Ben


signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Notes from Ben's "contribute to ghc" discussion

[Ben Gamari]

Richard Fung  writes:

>> Indeed we do! If you ever have questions just ask me via IRC or email.
>> I'd be very happy to help.
>
> First of all thank you for the help you've given me so far.
>
Of course! I'm happy that I could help.

Moreover, thanks for writing this. This sort of feedback is worth its
byte count in gold.

> Maybe I'm different from others, but my workflow as a newcomer was just
> reading https://ghc.haskell.org/trac/ghc/wiki/Newcomers.
>
> My extremely unsophisticated idea is to just update this wiki page so that
> it's obvious there are people who are willing to mentor newcomers. It seems
> as though we already have mentors or people willing to be mentors, but we
> also have people who did not know this was available.
>
That is a great point; it's easy for me to forget how I felt when I was
a beginner. I've added a brief paragraph to the Newcomers page,

If you have any questions along the way don't hesitate to reach out
to the community. There are people on the mailing lists and IRC who
will gladly help you (although you may need to be patient). Don't
forget that all GHC developers are still learning; your question is
never too silly to ask.

Can you see any way this could be improved?

> More specifically, I think it would be useful if under the "Finding a
> Ticket" section, as an alternative to just picking a ticket, we suggest
> people to ask either through email or on IRC for a starter ticket. Then,
> hopefully the people who would be willing to mentor this person can suggest
> tickets they are equipped to deal with themselves.
>
That is a fair point; I've added some language to the Newcomers page
encouraging these sorts of inqueries,

== Finding a ticket ==

Now that you can build GHC, let's get hacking. But first, you'll
need to identify a goal. GHC's Trac tickets are a great place to
find starting points. You are encouraged to ask for a starting point
on IRC or the ghc-devs mailing list. There someone familiar with the
process can help you find a ticket that matches your expertise and
help you when troubles arise.

If you want to get a taste for possible starting tasks, below is a
list of tickets that appear to be "low-hanging fruit" -- things that
might be reasonable for a newcomer to GHC hacking. Of course, we
can't ever be sure of how hard a task is before doing it, so
apologies if one of these is too hard.

Is this better?

> By having newcomers ask for a ticket, we can guarantee that if this person
> gets a response there would be a mentor available. Also, if someone is too
> busy to be a mentor, then that person could just choose not to volunteer so
> that nobody should get overburdened, or at least any more overburdened than
> they already are.
>
> It might seem silly and I am probably just too shy, but as someone new I am
> always very hesitant to email the entire mailing list for help. On the
> other hand, I also feel bad for emailing a specific person because I figure
> they are likely very busy. If I were assigned someone to ask for help,
> especially someone who volunteered himself or herself, I suspect I would
> not feel so embarrassed to ask for help. I probably should have asked for
> help more on IRC but to be honest I have only used IRC once or twice in my
> life, incidentally also for help on Haskell, so it's not something I really
> remember.
>
IRC is a great tool; personally I felt much more empowered to ask
questions after I started using it.

Regardless, I'm certain that you are not the only one who is reluctant
to ask a large group.  I've now tried to really emphasize the importance of
asking questions on the Newcomers page but I agree that having a mentor
would lower the barrier to asking significantly.

Cheers,

- Ben


signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Notes from Ben's "contribute to ghc" discussion

[Michael Sloan]

On Mon, Sep 26, 2016 at 12:40 PM, Simon Marlow  wrote:
> On 26 September 2016 at 20:13, Ben Gamari  wrote:
>>
>> Simon Marlow  writes:
>>
>> > I would rather we *didn't* accept contributions via github, even for
>> > small
>> > patches, and instead put more effort into streamlining the Phabricator
>> > workflow.
>> >
>> >
>> >- Adding another input method complicates the workflow, users have to
>> >decide which one to use
>> >
>> I think we would want to try to sell the GitHub route as "if you would
>> like to contribute then we would strongly prefer you use Phabricator,
>> but if you must and it's a small patch, we will accept it via GitHub."
>
>
> But this is opening the floodgates a crack... how do we know what a "small"
> patch is?  What happens when someone submits a patch that's too large?  The
> patches will get larger, we'll have to do code reviews on two different
> tools, and it will be really hard to go back.  I just have a bad feeling
> about this.

I agree that this would certainly happen - people would get used to
the new workflow and want to use it for large patches.  I've said
similar things in a post I made to Carter's thread about a
ghc-simple-patch-propose list.  Please consider this approach:

If a patch requires substantial revision, move it to Phabricator.  How
do we know when it requires substantial revision?  There are two
conditions for this:

1) When it is clear to the reviewer that it will take multiple iterations

2) After a single iteration of review has occurred on GitHub, and
there is still more to do.

This way, any substantial review process will be captured as a differential.

We need a way to make this as easy and efficient as possible for
maintainers and contributors alike.  In particular, maintainer /
reviewer time is very valuable.  As such, I propose the following:

1) A tool called "ghc-hub", which supports "ghc-hub migrate URL", to
migrate a PR to a Differential, without migrating any review metadata
(to keep the implementation simple).  It would also support "ghc-hub
merge URL", .  Using PR URLs on the commandline like this is inspired
by github's hub tool - https://github.com/github/hub .

2) Eventually, have a GitHub bot which does the following:

  * Notices if a patch is particularly large, and recommends using the
"ghc-hub" tool to perform the migration.

  * Notices if a patch has already gone through a review and hasn't
been merged for a while, and automatically migrates it to a
differential.

Note that having these tools ready is not necessary to begin this new
workflow, but I think they will be helpful for making this new
workflow a sustainable approach.

If you guys are on board with this approach, I would enjoy writing the
initial version of "ghc-hub". Though I cannot at this time guarantee
that I would be willing to entirely champion / maintain it - I'll need
some help.

>> >- Github is not integrated with our other infrastructure, while
>> >Phabricator is
>> >
>> True, but I suspect for the small documentation patches that we are
>> currently consider this shouldn't matter so much.
>>
>> >- Mutliple sources of contributions makes life harder for maintainers
>> >
>> It does certainly put yet another task on our plates, but I would argue
>> that it's actually easier than accepting patches via Trac, which we
>> already do.
>
>
> We should stop accepting patches via Trac too :)
>
> Cheers
> Simon
>
>
>
>>
>> >- I also like the idea of auto-push if validate succeeds.  Or a
>> > button
>> >that you can press on the diff that would do the same thing, so you
>> > can get
>> >code review first.
>> >
>> To be clear, I'm a bit weary of opening up the auto-push feature to new
>> contributors. While regular contributors know what changes can be safely
>> pushed and which require review, we have no guarantee that a new
>> contributor has developed these sensibilities.
>>
>> >- +1 to making the manual easier to build.  The same goes for
>> > Haddocks;
>> >it's really hard to make a simple patch to the docs and test it right
>> > now.
>> >
>> The users guide should be quite possible to do.
>>
>> I don't believe there is any reliable way to allow a contributor to
>> build the haddocks without having built GHC (since you need GHC master to
>> parse `base`, et al.); that being said, we could have Harbormaster
>> upload built documentation somewhere and then leave a link to it on the
>> Diff.
>>
>> > One other thing that came up but wasn't mentioned in the notes: let's be
>> > more prompt about reverting patches that break validate, even if they
>> > only
>> > break a test.  Now that we have better CI support, we can easily
>> > identify
>> > breaking patches and revert them.
>> >
>> Agreed.
>>
>> Cheers,
>>
>> - Ben
>>
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-d

Re: Notes from Ben's "contribute to ghc" discussion

[Simon Marlow]

On 26 September 2016 at 20:13, Ben Gamari  wrote:

> Simon Marlow  writes:
>
> > I would rather we *didn't* accept contributions via github, even for
> small
> > patches, and instead put more effort into streamlining the Phabricator
> > workflow.
> >
> >
> >- Adding another input method complicates the workflow, users have to
> >decide which one to use
> >
> I think we would want to try to sell the GitHub route as "if you would
> like to contribute then we would strongly prefer you use Phabricator,
> but if you must and it's a small patch, we will accept it via GitHub."
>

But this is opening the floodgates a crack... how do we know what a "small"
patch is?  What happens when someone submits a patch that's too large?  The
patches will get larger, we'll have to do code reviews on two different
tools, and it will be really hard to go back.  I just have a bad feeling
about this.

>- Github is not integrated with our other infrastructure, while
> >Phabricator is
> >
> True, but I suspect for the small documentation patches that we are
> currently consider this shouldn't matter so much.
>
> >- Mutliple sources of contributions makes life harder for maintainers
> >
> It does certainly put yet another task on our plates, but I would argue
> that it's actually easier than accepting patches via Trac, which we
> already do.
>

We should stop accepting patches via Trac too :)

Cheers
Simon




> >- I also like the idea of auto-push if validate succeeds.  Or a button
> >that you can press on the diff that would do the same thing, so you
> can get
> >code review first.
> >
> To be clear, I'm a bit weary of opening up the auto-push feature to new
> contributors. While regular contributors know what changes can be safely
> pushed and which require review, we have no guarantee that a new
> contributor has developed these sensibilities.
>
> >- +1 to making the manual easier to build.  The same goes for
> Haddocks;
> >it's really hard to make a simple patch to the docs and test it right
> now.
> >
> The users guide should be quite possible to do.
>
> I don't believe there is any reliable way to allow a contributor to
> build the haddocks without having built GHC (since you need GHC master to
> parse `base`, et al.); that being said, we could have Harbormaster
> upload built documentation somewhere and then leave a link to it on the
> Diff.
>
> > One other thing that came up but wasn't mentioned in the notes: let's be
> > more prompt about reverting patches that break validate, even if they
> only
> > break a test.  Now that we have better CI support, we can easily identify
> > breaking patches and revert them.
> >
> Agreed.
>
> Cheers,
>
> - Ben
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Notes from Ben's "contribute to ghc" discussion

[Richard Fung]

>
> Indeed we do! If you ever have questions just ask me via IRC or email.
> I'd be very happy to help.


First of all thank you for the help you've given me so far.

Maybe I'm different from others, but my workflow as a newcomer was just
reading https://ghc.haskell.org/trac/ghc/wiki/Newcomers.

My extremely unsophisticated idea is to just update this wiki page so that
it's obvious there are people who are willing to mentor newcomers. It seems
as though we already have mentors or people willing to be mentors, but we
also have people who did not know this was available.

More specifically, I think it would be useful if under the "Finding a
Ticket" section, as an alternative to just picking a ticket, we suggest
people to ask either through email or on IRC for a starter ticket. Then,
hopefully the people who would be willing to mentor this person can suggest
tickets they are equipped to deal with themselves.

By having newcomers ask for a ticket, we can guarantee that if this person
gets a response there would be a mentor available. Also, if someone is too
busy to be a mentor, then that person could just choose not to volunteer so
that nobody should get overburdened, or at least any more overburdened than
they already are.

It might seem silly and I am probably just too shy, but as someone new I am
always very hesitant to email the entire mailing list for help. On the
other hand, I also feel bad for emailing a specific person because I figure
they are likely very busy. If I were assigned someone to ask for help,
especially someone who volunteered himself or herself, I suspect I would
not feel so embarrassed to ask for help. I probably should have asked for
help more on IRC but to be honest I have only used IRC once or twice in my
life, incidentally also for help on Haskell, so it's not something I really
remember.

On Mon, Sep 26, 2016 at 12:13 PM, Ben Gamari  wrote:

> Simon Marlow  writes:
>
> > I would rather we *didn't* accept contributions via github, even for
> small
> > patches, and instead put more effort into streamlining the Phabricator
> > workflow.
> >
> >
> >- Adding another input method complicates the workflow, users have to
> >decide which one to use
> >
> I think we would want to try to sell the GitHub route as "if you would
> like to contribute then we would strongly prefer you use Phabricator,
> but if you must and it's a small patch, we will accept it via GitHub."
>
> >- Github is not integrated with our other infrastructure, while
> >Phabricator is
> >
> True, but I suspect for the small documentation patches that we are
> currently consider this shouldn't matter so much.
>
> >- Mutliple sources of contributions makes life harder for maintainers
> >
> It does certainly put yet another task on our plates, but I would argue
> that it's actually easier than accepting patches via Trac, which we
> already do.
>
> > Let's make the Phabricator workflow easier.
> >
> >- Why not put arc in the repo, or provide a script that automatically
> >downloads it and sets it up?
> >
> I'm not sure how much of a difference placing arc in the repo will make;
> the user will still at very least need to install PHP manually.
>
> >- I also like the idea of auto-push if validate succeeds.  Or a button
> >that you can press on the diff that would do the same thing, so you
> can get
> >code review first.
> >
> To be clear, I'm a bit weary of opening up the auto-push feature to new
> contributors. While regular contributors know what changes can be safely
> pushed and which require review, we have no guarantee that a new
> contributor has developed these sensibilities.
>
> >- +1 to making the manual easier to build.  The same goes for
> Haddocks;
> >it's really hard to make a simple patch to the docs and test it right
> now.
> >
> The users guide should be quite possible to do.
>
> I don't believe there is any reliable way to allow a contributor to
> build the haddocks without having built GHC (since you need GHC master to
> parse `base`, et al.); that being said, we could have Harbormaster
> upload built documentation somewhere and then leave a link to it on the
> Diff.
>
> > One other thing that came up but wasn't mentioned in the notes: let's be
> > more prompt about reverting patches that break validate, even if they
> only
> > break a test.  Now that we have better CI support, we can easily identify
> > breaking patches and revert them.
> >
> Agreed.
>
> Cheers,
>
> - Ben
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Notes from Ben's "contribute to ghc" discussion

[Ben Gamari]

Simon Marlow  writes:

> I would rather we *didn't* accept contributions via github, even for small
> patches, and instead put more effort into streamlining the Phabricator
> workflow.
>
>
>- Adding another input method complicates the workflow, users have to
>decide which one to use
>
I think we would want to try to sell the GitHub route as "if you would
like to contribute then we would strongly prefer you use Phabricator,
but if you must and it's a small patch, we will accept it via GitHub."

>- Github is not integrated with our other infrastructure, while
>Phabricator is
>
True, but I suspect for the small documentation patches that we are
currently consider this shouldn't matter so much.

>- Mutliple sources of contributions makes life harder for maintainers
>
It does certainly put yet another task on our plates, but I would argue
that it's actually easier than accepting patches via Trac, which we
already do.

> Let's make the Phabricator workflow easier.
>
>- Why not put arc in the repo, or provide a script that automatically
>downloads it and sets it up?
>
I'm not sure how much of a difference placing arc in the repo will make;
the user will still at very least need to install PHP manually.

>- I also like the idea of auto-push if validate succeeds.  Or a button
>that you can press on the diff that would do the same thing, so you can get
>code review first.
>
To be clear, I'm a bit weary of opening up the auto-push feature to new
contributors. While regular contributors know what changes can be safely
pushed and which require review, we have no guarantee that a new
contributor has developed these sensibilities.

>- +1 to making the manual easier to build.  The same goes for Haddocks;
>it's really hard to make a simple patch to the docs and test it right now.
>
The users guide should be quite possible to do.

I don't believe there is any reliable way to allow a contributor to
build the haddocks without having built GHC (since you need GHC master to
parse `base`, et al.); that being said, we could have Harbormaster
upload built documentation somewhere and then leave a link to it on the
Diff.

> One other thing that came up but wasn't mentioned in the notes: let's be
> more prompt about reverting patches that break validate, even if they only
> break a test.  Now that we have better CI support, we can easily identify
> breaking patches and revert them.
>
Agreed.

Cheers,

- Ben



signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion

[Michael Sloan]

Argh, sent too soon.  The first paragraph, revised:

This sounds like an ideal solution, Ben!  As has been discussed many
times before, GitHub has many users familiar with its interface.  By
allowing GitHub PRs, the initial contribution barrier will be lowered. If
there is an easy and straightforward process for shifting big patches
to Phabricator, then people who are regularly contributing via GitHub
PRs can be incrementally on-boarded to the Phabricator / Arcanist
workflow.

On Mon, Sep 26, 2016 at 12:07 PM, Michael Sloan  wrote:
> This sounds like an ideal solution, Ben!  As has been discussed many
> times before, GitHub has many users familiar with its interface.  By
> allowing GitHub PRs, the initial contribution
>
> I think it would be acceptable for larger GitHub PRs to have some
> automated boilerplate response.  Ideally this would look like:
>
> """
> Thanks for making this patch!  I've turned this into a Phab
> Differential xxx and closed this PR.  Please create a differential
> account associated with your email address ..."
> """
>
> The email address can be automatically pulled from commit metadata.
> If one is absent, then this automated process isn't possible.  If it
> is present and
>
> So, I'm imagining a utility that interfaces between both GitHub and
> Phab,allowing the following commands:
>
> * "ghc-hub migrate https://github.com/ghc/ghc/pull/1"; - migrates the
> patch to differential.  It may attempt to migrate body and title of
> the initial post, but lets not bother with migrating any review data.
>
> * "ghc-hub merge https://github.com/ghc/ghc/pull/1"; - merges the
> patch.  This is used for merging small patches.  It would not do an
> automated push.  Maybe have "--push" also perform the push?  So like
> if you are on master, then "ghc-hub merge
> https://github.com/ghc/ghc/pull/1 --push" would merge the patches and
> push to master.
>
> How does this sound?  I like the idea a lot, and would enjoy helping
> with implementation, time permitting.  I could possibly start hacking
> on it if others give the go ahead of "Yes, lets do that".
>
> -Michael
>
> On Mon, Sep 26, 2016 at 11:45 AM, Ben Gamari  wrote:
>> Carter Schonwald  writes:
>>
>>> In writing the following huge wall of text, I had and idea that I think
>>> many folks would find palatable:
>>>
>>> What if simple small patches (such as hypothetical drive by doc patches )
>>> had a mailing list where folks could email the simple / small patches as
>>> email attachments plus a body text that summarizes the patch, what it does,
>>> and why it's simple!
>>>
>> I completely agree that for small (e.g. documentation) patches our
>> current system is quite heavy. For this reason I suggested at ICFP that
>> we simply begin accepting small patches via GitHub pull requests.
>> Frankly, this is less work for me than merging patches from a mailing
>> list and I believe many users feel that GitHub is more accessible than a
>> mailing list.
>>
>> The problem of course is what subset of patches do we want to allow to
>> be taken via GitHub. My suggested answer to that is any patch which, if
>> I were to write it myself, I would feel comfortable pushing directly to
>> the tree.
>>
>> Then there is the question of what do we do with pull requests opened
>> which do not satisfy this criterion. In this case I would likely open a
>> Phabricator Differential with the pull request and close the pull
>> request with a link to the Diff. In the ideal case this will inspire the
>> contributor to join the review process on Phabricator; in the worst case
>> review turns up issues in the patch and the user gives up. Either way, at
>> least the contributor feels his patch has been seen and given the
>> attention it deserves.
>>
>> Cheers,
>>
>> - Ben
>>
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion

[Michael Sloan]

This sounds like an ideal solution, Ben!  As has been discussed many
times before, GitHub has many users familiar with its interface.  By
allowing GitHub PRs, the initial contribution

I think it would be acceptable for larger GitHub PRs to have some
automated boilerplate response.  Ideally this would look like:

"""
Thanks for making this patch!  I've turned this into a Phab
Differential xxx and closed this PR.  Please create a differential
account associated with your email address ..."
"""

The email address can be automatically pulled from commit metadata.
If one is absent, then this automated process isn't possible.  If it
is present and

So, I'm imagining a utility that interfaces between both GitHub and
Phab,allowing the following commands:

* "ghc-hub migrate https://github.com/ghc/ghc/pull/1"; - migrates the
patch to differential.  It may attempt to migrate body and title of
the initial post, but lets not bother with migrating any review data.

* "ghc-hub merge https://github.com/ghc/ghc/pull/1"; - merges the
patch.  This is used for merging small patches.  It would not do an
automated push.  Maybe have "--push" also perform the push?  So like
if you are on master, then "ghc-hub merge
https://github.com/ghc/ghc/pull/1 --push" would merge the patches and
push to master.

How does this sound?  I like the idea a lot, and would enjoy helping
with implementation, time permitting.  I could possibly start hacking
on it if others give the go ahead of "Yes, lets do that".

-Michael

On Mon, Sep 26, 2016 at 11:45 AM, Ben Gamari  wrote:
> Carter Schonwald  writes:
>
>> In writing the following huge wall of text, I had and idea that I think
>> many folks would find palatable:
>>
>> What if simple small patches (such as hypothetical drive by doc patches )
>> had a mailing list where folks could email the simple / small patches as
>> email attachments plus a body text that summarizes the patch, what it does,
>> and why it's simple!
>>
> I completely agree that for small (e.g. documentation) patches our
> current system is quite heavy. For this reason I suggested at ICFP that
> we simply begin accepting small patches via GitHub pull requests.
> Frankly, this is less work for me than merging patches from a mailing
> list and I believe many users feel that GitHub is more accessible than a
> mailing list.
>
> The problem of course is what subset of patches do we want to allow to
> be taken via GitHub. My suggested answer to that is any patch which, if
> I were to write it myself, I would feel comfortable pushing directly to
> the tree.
>
> Then there is the question of what do we do with pull requests opened
> which do not satisfy this criterion. In this case I would likely open a
> Phabricator Differential with the pull request and close the pull
> request with a link to the Diff. In the ideal case this will inspire the
> contributor to join the review process on Phabricator; in the worst case
> review turns up issues in the patch and the user gives up. Either way, at
> least the contributor feels his patch has been seen and given the
> attention it deserves.
>
> Cheers,
>
> - Ben
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Notes from Ben's "contribute to ghc" discussion

[Ben Gamari]

Jason Dagit  writes:

> On Sat, Sep 24, 2016 at 6:29 PM, Christopher Allen 
> wrote:
>
>> I'd be willing to help with work required to open up GHC development
>> more along multiple lines including:
>>
>> Bots/automation for Github
>>
>> Talking to Rust devs about what works, what doesn't
>>
>
> Last year I approached some folks in the rust community because I wanted to
> learn how to contribute to the rust compiler. In my experience, the really
> special thing they had was an identified pool of contributors who were
> willing and able to provide mentoring. I got hooked up with a mentor and
> that made all the difference. I had a real live person I could talk to
> about the process, the process-meta, and that person had context with me.
> Pretty much everything else was just details.
>
> GHC dev probably has mentors too, but I don't know because I've never
> thought to check or ask.
>
Indeed we do! If you ever have questions just ask me via IRC or email.
I'd be very happy to help. Even while I may not know the answer I (or
anyone else in #ghc) will likely be able to send you to someone who
does.

Cheers,

- Ben



signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion

[Ben Gamari]

Phyx  writes:

> I dislike this approach, having to already deal with a project that does
> patches via mailing lists it is very hard to follow conversations. As soon
> as multiple people get involved things fall apart.
>
I think accepting pull requests via GitHub can be done with minimal
involvement from existing contributors. All we need is one or two people
to keep an eye on the PR queue and merge or transition-to-Phabricator
PRs as they arrive.

> I have multiple mailing rules and other things just so I can keep track of
> comments. And then volume makes patches disappear into a void.
>
> We already have a lightweight process. Lots of people just attach the patch
> to trac. And we still accept it.
>
> Going to trac forces you to give me useful information about what you are
> trying to fix. A mailing list doesn't force a submitter to give me basic
> information about the patch. Such as which platform it effects.
>
A commit message as you are forced to provide by Git should
usually be sufficient here. Of course, there are always cases where
users will offer insufficient commit descriptions, but this is something
that only the pull request monitors should need to worry about.

Cheers,

- Ben


signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion

[Ben Gamari]

Carter Schonwald  writes:

> In writing the following huge wall of text, I had and idea that I think
> many folks would find palatable:
>
> What if simple small patches (such as hypothetical drive by doc patches )
> had a mailing list where folks could email the simple / small patches as
> email attachments plus a body text that summarizes the patch, what it does,
> and why it's simple!
>
I completely agree that for small (e.g. documentation) patches our
current system is quite heavy. For this reason I suggested at ICFP that
we simply begin accepting small patches via GitHub pull requests.
Frankly, this is less work for me than merging patches from a mailing
list and I believe many users feel that GitHub is more accessible than a
mailing list.

The problem of course is what subset of patches do we want to allow to
be taken via GitHub. My suggested answer to that is any patch which, if
I were to write it myself, I would feel comfortable pushing directly to
the tree.

Then there is the question of what do we do with pull requests opened
which do not satisfy this criterion. In this case I would likely open a
Phabricator Differential with the pull request and close the pull
request with a link to the Diff. In the ideal case this will inspire the
contributor to join the review process on Phabricator; in the worst case
review turns up issues in the patch and the user gives up. Either way, at
least the contributor feels his patch has been seen and given the
attention it deserves.

Cheers,

- Ben


signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Notes from Ben's "contribute to ghc" discussion

[Ben Gamari]

Christopher Allen  writes:

>>I think the we'd want to restrict this to Diffs submitted by
>>contributors who already possess commit bits and specifically include
>>a "no-review" tag in the summary.
>
> Is this intended to address the issues new contributors have in
> contributing to GHC? This looks more insider stuff that misses the
> point if so.
>
To reiterate Joachim's point, this is a feature to try to make it easier
for contributors who would normally push directly `master` to instead
use Phabricator and hence go through CI.

The tree being broken is bad for everyone: users, new- and
regular-contributors alike. I think it's fair to say that this change
will improve everyone's experience, even if it's aimed at regular
contributors.

> If new contributors are not part of a conversation about contributing
> to GHC, when and where did that conversation happen and what is being
> done about it?
>
It is important to remember that the ideas that were described at the
head of this thread arose at a discussion at ICFP; I think it's fair to
say that there is significantly more GHC-hacking experience per head in
this group than average. Consequently, it's quite understandable if the
ideas discussed there may have focused more on regular contributors than
new contributors.

However, I would like to emphasize that this does /not/ mean that we
have no interest in hearing from beginning contributors. I would love to
hear from those who feel lost in the current scheme.

I spoke with a number of new contributors at ICFP who reported varying
degrees of success. I would love to hear more experiences!

Cheers,

- Ben


signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion

[John Wiegley]

> "CS" == Carter Schonwald  writes:

CS> What if simple small patches (such as hypothetical drive by doc patches )
CS> had a mailing list where folks could email the simple / small patches as
CS> email attachments plus a body text that summarizes the patch, what it
CS> does, and why it's simple!

Btw, the "patchwork" system was created to do just this: Observe patches sent
to a mailing list, and collect them into a web-based list, where discussion
and review can happen in a patch-centric way. Example:

https://patchwork.kernel.org/project/kvm/list/

The Linux project has been using this system to manage patch contributions for
many years now.

It may be a bit too webby, but it's example of another system that tries to
address this bit of the process.

-- 
John Wiegley  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com  60E1 46C4 BD1A 7AC1 4BA2
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Notes from Ben's "contribute to ghc" discussion

[Matthew Pickering]

Thank you for this comment Anthony.
I thought about it over the last day and think you have it spot on.
This is the key sentence:

> The truth is that it what I complained about is *not a problem*
> for GHC devs in so far as they are happy doing GHC development!

It seems that the point that you are getting at is that currently the
development process is heavily optimised for existing developers.
There are quite a few moving parts but once you get a handle on them
all it works well for me at least. The argument seems
to be that we should (much) more heavily optimise for new
contributors. (I think this is what Chris is saying as well).

What I am trying to say is that we should meet in the middle.
We should keep using phabricator as for regular contributors github is
too painful to use for a project of GHC's size (as rust exemplifies
with the custom bots). In order to improve the newcomer's experience
it would be beneficial to consolidate as much as possible to one
domain so that new contributors have only one place to look. Does this
sound sensible to you?

I would also like to take this chance to apologies to Chris for
cutting off the discussion we were having. I would appreciate it if
you would directly respond to the suggestions in
this message.

Matt

On Sun, Sep 25, 2016 at 2:13 AM, Anthony Cowley  wrote:
> On Sat, Sep 24, 2016 at 8:17 PM, Matthew Pickering
>  wrote:
>> I think this comment is useful because it highlights the point that it
>> isn't very clear what "the point" even is.
>>
> [snip]
>>
>> Ultimately, I'm not sure what exactly what the point is. I read posts
>> like this ( http://www.arcadianvisions.com/blog/2016/ghc-contributing.html
>> ) and find myself disagreeing with almost every point. The comments in
>> the reddit thread provide most of the refutations. The post doesn't
>> address the
>> fact that the feature was a small syntactic change which as erik
>> pointed out, it perhaps the most difficult change to integrate as it
>> must certainly pay it's way.
>
>
> Matthew, if you are going to claim that you champion the concerns of
> new contributers, you must do more than dismiss criticism without
> offering a single word of reply. As I was involved in the discussion
> you linked and remember it very differently than you, I went back to
> try to understand what you possibly could have read. The top-level
> replies are:
>
> - Me clarifying that I like GHC
> - Someone who likes arc and notes, but hates the build system
> - Someone who argued that a syntactic change would be the "deep end of
> the difficulty pool" because they apparently did not realize the patch
> was already done.
> - Someone arguing that consistent style is not important
> - A strangely worded suggestion that there exist refutations but it
> would be inappropriate to mention them
> - Agreement that GHC dev is off-putting
> - Agreement that GHC dev is off-putting
> - GHC is a great compiler
> - Someone who likes GHC dev
> - A pro GitHub post
> - Someone complaining about how I was treated
>
> So, you read those comments in response to a specific, itemized,
> literally bullet-pointed complaint that getting changes into GHC by an
> outsider requires an ill-defined marathon of mailing lists and forums
> in which GHC devs do not participate very much, and what you took away
> from it was that the post was largely refuted.
>
> GHC is a fine research compiler and several people do tremendous work
> on it. But please do not keep asking what the problem is if you are
> going to completely ignore it when it is written down time and time
> again. The truth is that it what I complained about is *not a problem*
> for GHC devs in so far as they are happy doing GHC development!
> Mystery solved, we can all move on with our lives productively using
> GHC or contributing to it. Chris's reaction to the title of the talk
> is entirely understandable to me, as I had interpreted it the same
> way.
>
> Anthony
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Notes from Ben's "contribute to ghc" discussion

[Simon Marlow]

I would rather we *didn't* accept contributions via github, even for small
patches, and instead put more effort into streamlining the Phabricator
workflow.

   - Adding another input method complicates the workflow, users have to
   decide which one to use
   - Github is not integrated with our other infrastructure, while
   Phabricator is
   - Mutliple sources of contributions makes life harder for maintainers

Let's make the Phabricator workflow easier.

   - Why not put arc in the repo, or provide a script that automatically
   downloads it and sets it up?
   - I also like the idea of auto-push if validate succeeds.  Or a button
   that you can press on the diff that would do the same thing, so you can get
   code review first.
   - +1 to making the manual easier to build.  The same goes for Haddocks;
   it's really hard to make a simple patch to the docs and test it right now.

One other thing that came up but wasn't mentioned in the notes: let's be
more prompt about reverting patches that break validate, even if they only
break a test.  Now that we have better CI support, we can easily identify
breaking patches and revert them.

Cheers

Simon

On 24 September 2016 at 02:44, Simon Peyton Jones via ghc-devs <
ghc-devs@haskell.org> wrote:

> Friends
>
>
>
> Here are the notes I took from session 2 of the Haskell Implementors
> Meeting.  The bolding is my choice of emphasis.
>
>
>
> Simon
>
>
>
> ·Doc bugs.Two kinds
>
> o   Typos.   Friction stops me
>
> o   Explanations needed e.g. read/show
>
> ·Lightweight pushes
>
> ·Make user manual into its own repo, to make it easier to take
> pull requests.  But that makes it harder when making synchronised changes
> to GHC and user manual.
>
> ·*Auto-push*: Ability to push to Phab and have it committed
> automatically if it validates.
>
> ·Style guides.  Is having a defined style solving a problem we
> don’t really have?  One piece of guidance: *adhere to the style of the
> surrounding code*.  Low priority.
>
> ·Docker images.   We should have one.
>
> ·Remove old documentation!
>
> ·Cross compilation is difficult.
>
> ·*Have a GHC StackOverflow on haskell.org *
> (Jacob Zalewski jakz...@gmail.com offers to do this! – thank you).  It
> has a useful new Documentation feature.   Eg this would be good for “how do
> I look up a RdrName to get a Name… there seem to be six different functions
> that do that”.
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion

[Phyx]

I dislike this approach, having to already deal with a project that does
patches via mailing lists it is very hard to follow conversations. As soon
as multiple people get involved things fall apart.

I have multiple mailing rules and other things just so I can keep track of
comments. And then volume makes patches disappear into a void.

We already have a lightweight process. Lots of people just attach the patch
to trac. And we still accept it.

Going to trac forces you to give me useful information about what you are
trying to fix. A mailing list doesn't force a submitter to give me basic
information about the patch. Such as which platform it effects.

Also you can use phabricator.haskell.org without arc. You can manually
upload a patch file to it.
Again,  phabricator's summerary file I find very useful. It may be annoying
for drive by commiters, but when I have to come back to this code a year or
so later, I need to know why it was added.


On Mon, Sep 26, 2016, 07:34 Michael Sloan  wrote:

> I like this solution a lot, Carter!
>
> Mailing patches directly to the ghc-devs list could be intimidating
> for newcomers.  Having a list specific to patch review could make the
> process less intimidating.  From a perspective of overall contribution
> intimidation, these 2 pages make it seem like a ton of extra work to
> contribute to GHC:
>
> 1) https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/FixingBugs
> 2) https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/AddingFeatures
>
> Of course, I understand that these exist for a reason.  Contributing
> to GHC isn't easy, and it does need processes, and those processes
> should be followed!
>
> However, for documentation patches and minor fixes, these pages make
> it seem like you really have to put in quite a bit to get started, and
> that the process is bureaucratic.  Atop getting accounts setup and
> figuring out how to get ghc compiled, the amount of time investment to
> get in a simple patch already seems like it is on the order of hours,
> if not a full days worth of work.
>
> At the risk of accumulating spam, perhaps the list shouldn't even
> require membership?  Just have it filter based on containing an
> attachment (perhaps even require a "*.patch" attachment?)
>
> I also think that there should be an easy way to put a stop to
> iterating via email and sending .patch files, and escalate to a
> phabricator review.  Perhaps this could be scripted?  Is there any way
> for people to use phabricator without using archanist?  Not a
> criticism of the tech, but it is more to learn, and foreign to most.
>
>
> One thing I've learned from maintaining stack, is that it can be
> really helpful to accept patches that are imperfect.  Here's how this
> works:
>
> 1) Some user wants to fix something, and doesn't quite nail it.  Maybe
> makes some style mistakes, spelling errors in comments, or perhaps
> writes some part of the code in a less direct way than possible
>
> 2) If the overall change is an improvement and the fixes are easy, I
> go ahead and merge the imperfect patch, and then commit my own fixes
> to the issues I saw.  I then say something like "Thanks for the
> patch!!  I fixed a few things in e5cbda"
>
> I feel like this is a highly valuable approach.  The contributor
> appreciates being thanked, and also appreciates directly seeing the
> ways that their patch could have been better.
>
> This is antithetical to the "google style" of code review, where every
> single thing is nit-picked and the author must fix it.  I think that
> approach only works well when you already have an established
> membership to that culture of code review (particularly if you are
> getting paid for it).  With that approach, all of the bad behaviors
> get beaten out of contributors, and they eventually learn their
> lesson, and either leave or become good contributors.  I think this
> can scare some people off, that might otherwise become regular
> contributors.
>
>
> Who knows if this will work out, but I think it is really worth a
> shot!  Especially if the wiki is updated to indicate that there is now
> an "easy mode" for contributing to ghc.
>
> -Michael
>
> On Sun, Sep 25, 2016 at 3:02 PM, Carter Schonwald
>  wrote:
> > In writing the following huge wall of text, I had and idea that I think
> many
> > folks would find palatable:
> >
> > What if simple small patches (such as hypothetical drive by doc patches )
> > had a mailing list where folks could email the simple / small patches as
> > email attachments plus a body text that summarizes the patch, what it
> does,
> > and why it's simple!
> >
> > What's even nice about this is its future proof and even agnostic to how
> the
> > contributor made the change set locally! They could use mercurial or
> fossil
> > for all we care. Or github. Or whatever!
> >
> >
> >
> > My personal stance is that ghc already way easier to contribute to / get
> > involved with than it was 2-5 years ago.  This is even more impressive
> whe

Re: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion

[Michael Sloan]

I like this solution a lot, Carter!

Mailing patches directly to the ghc-devs list could be intimidating
for newcomers.  Having a list specific to patch review could make the
process less intimidating.  From a perspective of overall contribution
intimidation, these 2 pages make it seem like a ton of extra work to
contribute to GHC:

1) https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/FixingBugs
2) https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/AddingFeatures

Of course, I understand that these exist for a reason.  Contributing
to GHC isn't easy, and it does need processes, and those processes
should be followed!

However, for documentation patches and minor fixes, these pages make
it seem like you really have to put in quite a bit to get started, and
that the process is bureaucratic.  Atop getting accounts setup and
figuring out how to get ghc compiled, the amount of time investment to
get in a simple patch already seems like it is on the order of hours,
if not a full days worth of work.

At the risk of accumulating spam, perhaps the list shouldn't even
require membership?  Just have it filter based on containing an
attachment (perhaps even require a "*.patch" attachment?)

I also think that there should be an easy way to put a stop to
iterating via email and sending .patch files, and escalate to a
phabricator review.  Perhaps this could be scripted?  Is there any way
for people to use phabricator without using archanist?  Not a
criticism of the tech, but it is more to learn, and foreign to most.


One thing I've learned from maintaining stack, is that it can be
really helpful to accept patches that are imperfect.  Here's how this
works:

1) Some user wants to fix something, and doesn't quite nail it.  Maybe
makes some style mistakes, spelling errors in comments, or perhaps
writes some part of the code in a less direct way than possible

2) If the overall change is an improvement and the fixes are easy, I
go ahead and merge the imperfect patch, and then commit my own fixes
to the issues I saw.  I then say something like "Thanks for the
patch!!  I fixed a few things in e5cbda"

I feel like this is a highly valuable approach.  The contributor
appreciates being thanked, and also appreciates directly seeing the
ways that their patch could have been better.

This is antithetical to the "google style" of code review, where every
single thing is nit-picked and the author must fix it.  I think that
approach only works well when you already have an established
membership to that culture of code review (particularly if you are
getting paid for it).  With that approach, all of the bad behaviors
get beaten out of contributors, and they eventually learn their
lesson, and either leave or become good contributors.  I think this
can scare some people off, that might otherwise become regular
contributors.


Who knows if this will work out, but I think it is really worth a
shot!  Especially if the wiki is updated to indicate that there is now
an "easy mode" for contributing to ghc.

-Michael

On Sun, Sep 25, 2016 at 3:02 PM, Carter Schonwald
 wrote:
> In writing the following huge wall of text, I had and idea that I think many
> folks would find palatable:
>
> What if simple small patches (such as hypothetical drive by doc patches )
> had a mailing list where folks could email the simple / small patches as
> email attachments plus a body text that summarizes the patch, what it does,
> and why it's simple!
>
> What's even nice about this is its future proof and even agnostic to how the
> contributor made the change set locally! They could use mercurial or fossil
> for all we care. Or github. Or whatever!
>
>
>
> My personal stance is that ghc already way easier to contribute to / get
> involved with than it was 2-5 years ago.  This is even more impressive when
> you consider the number of contributors (who aren't students) that focus on
> ghc work full time has actually DECREASED over that period.
>
> Community engagement / management is a totally orthogonal skill from
> contributing. Both take effort.  Guiding new contributors requires both.
>
> My personal stance is that ghc keeps on getting better and getting more
> contributors.  And occasionally chatting about ways to make things better
> that we have the bandwidth to do is something that should happen every year
> or so. Like a health checkup.
>
> I suspect one funnel for improvement may be figuring out how to make it more
> visible how many contributors / how actively deved various subsystems are.
> I feel like many new folks veer towards subsystems that are already actively
> worked on, which are often the ones that are both the most mature and thus
> hardest to easily contribute to! Perhaps I should see if there's an easy way
> to quantify that in a way that's easy to communicate to new contributors.
> There's an interesting data presentation challenge in that!
>
> I've definitely found that for new potential contributors that orienting
> them to f

Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion

[Carter Schonwald]

In writing the following huge wall of text, I had and idea that I think
many folks would find palatable:

What if simple small patches (such as hypothetical drive by doc patches )
had a mailing list where folks could email the simple / small patches as
email attachments plus a body text that summarizes the patch, what it does,
and why it's simple!

What's even nice about this is its future proof and even agnostic to how
the contributor made the change set locally! They could use mercurial or
fossil for all we care. Or github. Or whatever!



My personal stance is that ghc already way easier to contribute to / get
involved with than it was 2-5 years ago.  This is even more impressive when
you consider the number of contributors (who aren't students) that focus on
ghc work full time has actually DECREASED over that period.

Community engagement / management is a totally orthogonal skill from
contributing. Both take effort.  Guiding new contributors requires both.

My personal stance is that ghc keeps on getting better and getting more
contributors.  And occasionally chatting about ways to make things better
that we have the bandwidth to do is something that should happen every year
or so. Like a health checkup.

I suspect one funnel for improvement may be figuring out how to make it
more visible how many contributors / how actively deved various subsystems
are.  I feel like many new folks veer towards subsystems that are already
actively worked on, which are often the ones that are both the most mature
and thus hardest to easily contribute to! Perhaps I should see if there's
an easy way to quantify that in a way that's easy to communicate to new
contributors. There's an interesting data presentation challenge in that!

I've definitely found that for new potential contributors that orienting
them to focus on subsystem that's important but doesn't get much activity
leads to more successful first contributions. But that requires someone
actively helping orient folks, which I like to think I've helped out with
at points in recent years.  Making this something that's easy to point at /
discover along with "newcomer tickets" might help a lot

Tweaking the way we do tickets or code review I think doesn't change the
important / fundamental challenges of doing a good patch for a project like
ghc or llvm.  (I think in some ways that llvm / gcc / clang are the right
size projects to compare ghc against )



On Saturday, September 24, 2016, Brandon Allbery 
wrote:

>
> On Sat, Sep 24, 2016 at 9:08 PM, Manuel M T Chakravarty <
> c...@justtesting.org
> > wrote:
>
>> Why are you so hostile to Chris? I don’t think that this is an
>> appropriate way to treat somebody who is making a suggestion in good faith.
>
>
> It may be in good faith. but it's not in good sense. There is a lot in the
> background that made Rust's setup possible, and he's not bringing that to
> the table, just assuming it'll somehow happen or that everyone else will
> drop everything for the next few months and make it happen. And I feel like
> he's being really pushy about committing already overworked people to this
> --- and insisting that anyone opposed must have a hidden agenda or
> otherwise cannot possibly have good reason to be opposed. It's not helpful
> at all; it's basically a good way to stall ghc for the next few months at
> least.
>
> --
> brandon s allbery kf8nh   sine nomine
> associates
> allber...@gmail.com 
>  ballb...@sinenomine.net
> 
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Notes from Ben's "contribute to ghc" discussion

[Jakub Zalewski]

Hi all,
I agree with Elliot that the idea of a mentor is really cool, but may not
be feasible at the moment. While the "on-demand" support (irc, reddit) from
the community is great, I believe that a potential new contributor should
be able to go as far as possible on their own because:
- newcomers may be hesitant to ask dumb questions about GHC (I know I was).
- newcomers may get turned away as the task will seems more complicated
that it is.
- the number of people working full-time on GHC is low.

For that, there needs to be a single and accessible place, where newcomers
can go and learn about ghc internals, the overall process, and what should
the do next to contribute.

Currently, there is wiki on trac, which is sometimes correct, sometimes
outdated, sometimes slightly chaotic, and sometimes difficult to use. In
addition to wiki, every member in the community is actively encouraged to
try out new features in ghc and blog about their experience, which works
perfectly fine for a tightly knit community, but presents an insurmountable
barrier of entry for newcomers.

I proposed using stack overflow, as they are adding a new feature called
[documentation](http://stackoverflow.com/documentation), which allows to
maintain a list of examples for a given tag. For instance, there is a stack
overflow documentation for [haskell](
http://stackoverflow.com/documentation/haskell/topics). Furthermore, I
believe that most potential newcomers will be familiar with using stack
overflow.

Next week, I will start cleaning up the wiki, as there are some pages and
guides for newcomers which are out of date and cause unnecessary headaches
for people that are unfamiliar with ghc. I will figure out and fill any
missing information regarding checking out the source and I will check if
there are any wiki entries that need to be deduplicated.

Best wishes,
Jakub

On Sun, 25 Sep 2016 at 20:47, Elliot Cameron  wrote:

> Oh how the chatroom hath slain its thousands, and email its ten thousands!
> Flattening real, hard-working, deep-thinking people into a few paragraphs
> of letters does such injustice to propinquity that it's a wonder it ever
> works at all!
>
> It's for that very reason I want to voice my approval of the idea of
> mentors. The thing that IRC cannot give you is a (real) name and a real
> face. The true fabric underlying any process or system is the people that
> make it happen. If the relationships of the people are broken, no virtual
> system will ever be able to recover the loss. I can't help but believe that
> the best way to improve the community of contributors is to improve the
> relationships of the people in it. Therefore, having a process of providing
> mentorship could be the most effective way to address the myriad technical
> difficulties of contributing to GHC. Love covers a multitude of wrongs. A
> friendly helper could easily make up for the technical infelicities or
> inexperience. In the long term, the improved strength of community could
> begin to address any technical issues as well.
>
> That said, I am not sure if mentorship is a burden the current "in-crowd"
> would be able to bear. But even with minimal hand-holding the improvement
> to propinquity could have significant effect.
>
> Lastly, as one who is building his business, in part, on the advantage of
> Haskell, I want to express my deep gratitude to both sides of the debate.
> Chris, your efforts to improve the "on-boarding" process are truly
> herculean and a massive investment to the community. Thank you! Matthew,
> and other core devs, your hard work and world-class insight make Haskell
> the technology that it is today and I cannot thank you enough.
>
> Elliot Cameron
>
> On Sun, Sep 25, 2016 at 4:35 AM, Matthew Pickering <
> matthewtpicker...@gmail.com> wrote:
>
>> If we loop this discussion back to the original post. There is a
>> suggestion in there which seems to be what you are looking for.
>>
>> >  Have a GHC StackOverflow on haskell.org   (Jacob Zalewski
>> jakz...@gmail.com offers to do this! – thank you).  It has a useful new
>> Documentation feature.   Eg this would be good for “how do I look up a
>> RdrName to get a Name… there seem to be six different functions that do
>> that”.
>>
>> It is also probably lost that I said there was a phabricator module
>> 'ponder' which gives this kind of functionality so it should be quick
>> and easy to setup.
>>
>> Matt
>>
>> On Sun, Sep 25, 2016 at 9:23 AM, Harendra Kumar
>>  wrote:
>> >
>> >
>> > On 25 September 2016 at 12:48, Joachim Breitner <
>> m...@joachim-breitner.de>
>> > wrote:
>> >>
>> >> Hi,
>> >>
>> >> > It will be great to have something like that. Something that you
>> >> > figure out digging at ghc trac wiki pages, mailing lists, google
>> >> > search etc will be a few minutes job for a mentor. It may be a bit
>> >> > taxing on the mentors but they can limit how many newbies they are
>> >> > mentoring and also breed new mentors to keep the cycle going.
>> >>
>> >> I hope an

Re: Notes from Ben's "contribute to ghc" discussion

[Elliot Cameron]

Oh how the chatroom hath slain its thousands, and email its ten thousands!
Flattening real, hard-working, deep-thinking people into a few paragraphs
of letters does such injustice to propinquity that it's a wonder it ever
works at all!

It's for that very reason I want to voice my approval of the idea of
mentors. The thing that IRC cannot give you is a (real) name and a real
face. The true fabric underlying any process or system is the people that
make it happen. If the relationships of the people are broken, no virtual
system will ever be able to recover the loss. I can't help but believe that
the best way to improve the community of contributors is to improve the
relationships of the people in it. Therefore, having a process of providing
mentorship could be the most effective way to address the myriad technical
difficulties of contributing to GHC. Love covers a multitude of wrongs. A
friendly helper could easily make up for the technical infelicities or
inexperience. In the long term, the improved strength of community could
begin to address any technical issues as well.

That said, I am not sure if mentorship is a burden the current "in-crowd"
would be able to bear. But even with minimal hand-holding the improvement
to propinquity could have significant effect.

Lastly, as one who is building his business, in part, on the advantage of
Haskell, I want to express my deep gratitude to both sides of the debate.
Chris, your efforts to improve the "on-boarding" process are truly
herculean and a massive investment to the community. Thank you! Matthew,
and other core devs, your hard work and world-class insight make Haskell
the technology that it is today and I cannot thank you enough.

Elliot Cameron

On Sun, Sep 25, 2016 at 4:35 AM, Matthew Pickering <
matthewtpicker...@gmail.com> wrote:

> If we loop this discussion back to the original post. There is a
> suggestion in there which seems to be what you are looking for.
>
> >  Have a GHC StackOverflow on haskell.org   (Jacob Zalewski
> jakz...@gmail.com offers to do this! – thank you).  It has a useful new
> Documentation feature.   Eg this would be good for “how do I look up a
> RdrName to get a Name… there seem to be six different functions that do
> that”.
>
> It is also probably lost that I said there was a phabricator module
> 'ponder' which gives this kind of functionality so it should be quick
> and easy to setup.
>
> Matt
>
> On Sun, Sep 25, 2016 at 9:23 AM, Harendra Kumar
>  wrote:
> >
> >
> > On 25 September 2016 at 12:48, Joachim Breitner <
> m...@joachim-breitner.de>
> > wrote:
> >>
> >> Hi,
> >>
> >> > It will be great to have something like that. Something that you
> >> > figure out digging at ghc trac wiki pages, mailing lists, google
> >> > search etc will be a few minutes job for a mentor. It may be a bit
> >> > taxing on the mentors but they can limit how many newbies they are
> >> > mentoring and also breed new mentors to keep the cycle going.
> >>
> >> I hope and assume that already now that every possible contributor who
> >> has questions like this and asks (e.g. on irc) will get a helpful
> >> answer. Is that insufficient?
> >
> >
> > Maybe. Though irc seems to be quite popular among Haskell community and
> > other open source communities I have never been able to utilize it
> somehow.
> > I don't know if there is something wrong with it or with me. I installed
> an
> > irc client logged into it once or twice but never got hooked to it. Such
> > questions on ghc-devs maybe a nuisance for a lot of other people or at
> least
> > that's what I felt as a newbie. I usually tend to do a lot of homework
> > before sending a question to ghc-devs. Maybe a ghc-newbies like mailing
> list
> > (one more list!) can give the impression of a lower barrier for sending
> > stupid or operational questions.
> >
> > -harendra
> >
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Notes from Ben's "contribute to ghc" discussion

[Matthew Pickering]

If we loop this discussion back to the original post. There is a
suggestion in there which seems to be what you are looking for.

>  Have a GHC StackOverflow on haskell.org   (Jacob Zalewski jakz...@gmail.com 
> offers to do this! – thank you).  It has a useful new Documentation feature.  
>  Eg this would be good for “how do I look up a RdrName to get a Name… there 
> seem to be six different functions that do that”.

It is also probably lost that I said there was a phabricator module
'ponder' which gives this kind of functionality so it should be quick
and easy to setup.

Matt

On Sun, Sep 25, 2016 at 9:23 AM, Harendra Kumar
 wrote:
>
>
> On 25 September 2016 at 12:48, Joachim Breitner 
> wrote:
>>
>> Hi,
>>
>> > It will be great to have something like that. Something that you
>> > figure out digging at ghc trac wiki pages, mailing lists, google
>> > search etc will be a few minutes job for a mentor. It may be a bit
>> > taxing on the mentors but they can limit how many newbies they are
>> > mentoring and also breed new mentors to keep the cycle going.
>>
>> I hope and assume that already now that every possible contributor who
>> has questions like this and asks (e.g. on irc) will get a helpful
>> answer. Is that insufficient?
>
>
> Maybe. Though irc seems to be quite popular among Haskell community and
> other open source communities I have never been able to utilize it somehow.
> I don't know if there is something wrong with it or with me. I installed an
> irc client logged into it once or twice but never got hooked to it. Such
> questions on ghc-devs maybe a nuisance for a lot of other people or at least
> that's what I felt as a newbie. I usually tend to do a lot of homework
> before sending a question to ghc-devs. Maybe a ghc-newbies like mailing list
> (one more list!) can give the impression of a lower barrier for sending
> stupid or operational questions.
>
> -harendra
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Notes from Ben's "contribute to ghc" discussion

[Harendra Kumar]

On 25 September 2016 at 12:48, Joachim Breitner 
wrote:

> Hi,
>
> > It will be great to have something like that. Something that you
> > figure out digging at ghc trac wiki pages, mailing lists, google
> > search etc will be a few minutes job for a mentor. It may be a bit
> > taxing on the mentors but they can limit how many newbies they are
> > mentoring and also breed new mentors to keep the cycle going.
>
> I hope and assume that already now that every possible contributor who
> has questions like this and asks (e.g. on irc) will get a helpful
> answer. Is that insufficient?


Maybe. Though irc seems to be quite popular among Haskell community and
other open source communities I have never been able to utilize it
somehow.  I don't know if there is something wrong with it or with me. I
installed an irc client logged into it once or twice but never got hooked
to it. Such questions on ghc-devs maybe a nuisance for a lot of other
people or at least that's what I felt as a newbie. I usually tend to do a
lot of homework before sending a question to ghc-devs. Maybe a ghc-newbies
like mailing list (one more list!) can give the impression of a lower
barrier for sending stupid or operational questions.

-harendra
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Notes from Ben's "contribute to ghc" discussion

[Joachim Breitner]

Hi,

> It will be great to have something like that. Something that you
> figure out digging at ghc trac wiki pages, mailing lists, google
> search etc will be a few minutes job for a mentor. It may be a bit
> taxing on the mentors but they can limit how many newbies they are
> mentoring and also breed new mentors to keep the cycle going.

I hope and assume that already now that every possible contributor who
has questions like this and asks (e.g. on irc) will get a helpful
answer. Is that insufficient?

Greetings,
Joachim

-- 
Joachim “nomeata” Breitner
  m...@joachim-breitner.de • https://www.joachim-breitner.de/
  XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: nome...@debian.org

signature.asc
Description: This is a digitally signed message part
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Notes from Ben's "contribute to ghc" discussion

[Harendra Kumar]

It will be great to have something like that. Something that you figure out
digging at ghc trac wiki pages, mailing lists, google search etc will be a
few minutes job for a mentor. It may be a bit taxing on the mentors but
they can limit how many newbies they are mentoring and also breed new
mentors to keep the cycle going.

-harendra

On 25 September 2016 at 11:46, Jason Dagit  wrote:

>
>
> On Sat, Sep 24, 2016 at 6:29 PM, Christopher Allen 
> wrote:
>
>> I'd be willing to help with work required to open up GHC development
>> more along multiple lines including:
>>
>> Bots/automation for Github
>>
>> Talking to Rust devs about what works, what doesn't
>>
>
> Last year I approached some folks in the rust community because I wanted
> to learn how to contribute to the rust compiler. In my experience, the
> really special thing they had was an identified pool of contributors who
> were willing and able to provide mentoring. I got hooked up with a mentor
> and that made all the difference. I had a real live person I could talk to
> about the process, the process-meta, and that person had context with me.
> Pretty much everything else was just details.
>
> GHC dev probably has mentors too, but I don't know because I've never
> thought to check or ask.
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Notes from Ben's "contribute to ghc" discussion

[Jason Dagit]

On Sat, Sep 24, 2016 at 6:29 PM, Christopher Allen 
wrote:

> I'd be willing to help with work required to open up GHC development
> more along multiple lines including:
>
> Bots/automation for Github
>
> Talking to Rust devs about what works, what doesn't
>

Last year I approached some folks in the rust community because I wanted to
learn how to contribute to the rust compiler. In my experience, the really
special thing they had was an identified pool of contributors who were
willing and able to provide mentoring. I got hooked up with a mentor and
that made all the difference. I had a real live person I could talk to
about the process, the process-meta, and that person had context with me.
Pretty much everything else was just details.

GHC dev probably has mentors too, but I don't know because I've never
thought to check or ask.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Notes from Ben's "contribute to ghc" discussion

[Brandon Allbery]

On Sat, Sep 24, 2016 at 9:44 PM, Michael Sloan  wrote:

> It is irrelevant why Rust has an advantage. Lets please emulate their
> successful strategies instead of in-fighting.
>

Does that include having Mozilla Corp. backing them? What is your
suggestion for this?

I understand that you think this is an important cause for the dearth of
contributors --- I've watched enough would-be contributors bounce off the
code base (long before even considering the tooling) and give up to have
major doubts, as underlined by Richard's recent message --- but throwing
everything out and building a new infrastructure is not something that
happens by itself. It needs *people* and it needs *time*. And it's harder
(and needs more people and more time) when you have a couple decades' worth
of history (which Rust did not). If you have a solution to this problem,
I'm sure people would like to hear it.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Notes from Ben's "contribute to ghc" discussion

[Michael Sloan]

Sorry, but I see little sense in what you are bringjng to this discussion.
Chris's points sre explaining some systemic reasons WHY there is a dearth
of contributors, and attempting to make a constructive plan to address
them.  Why should GHC not try to emulate a community that has fantasic
cohesion, unity, and participation?

It is irrelevant why Rust has an advantage. Lets please emulate their
successful strategies instead of in-fighting.

To me it seems you are just attacking his view with bluster and ad hominem,
with undertones of a personal vendetta against Rust.

On Saturday, September 24, 2016, Brandon Allbery 
wrote:

>
> On Sat, Sep 24, 2016 at 9:08 PM, Manuel M T Chakravarty <
> c...@justtesting.org
> > wrote:
>
>> Why are you so hostile to Chris? I don’t think that this is an
>> appropriate way to treat somebody who is making a suggestion in good faith.
>
>
> It may be in good faith. but it's not in good sense. There is a lot in the
> background that made Rust's setup possible, and he's not bringing that to
> the table, just assuming it'll somehow happen or that everyone else will
> drop everything for the next few months and make it happen. And I feel like
> he's being really pushy about committing already overworked people to this
> --- and insisting that anyone opposed must have a hidden agenda or
> otherwise cannot possibly have good reason to be opposed. It's not helpful
> at all; it's basically a good way to stall ghc for the next few months at
> least.
>
> --
> brandon s allbery kf8nh   sine nomine
> associates
> allber...@gmail.com 
>  ballb...@sinenomine.net
> 
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Notes from Ben's "contribute to ghc" discussion

[Richard Fung]

I suppose I'll take this opportunity to bring this thread back on topic and
have everyone read my thoughts guilt free.

As a newcomer who recently submitted my first patch, I disagree with
Chris's points. I'm just a junior developer who has never worked on a
compiler before, so maybe the experience will be different for people from
other backgrounds. I guess you're allowed to disagree with me even if
you're from a similar background.

In my (short) experience, Github vs Phabricator, using Arc, and the points
mentioned in the linked blog like coding style and comments were all non
issues. Again, this is just my experience and others might feel
differently, but if so I encourage them to raise their points and hopefully
also explain in detail the issues encountered.

For me the only issue was being able to understand the code base. Sadly,
this was actually a huge barrier because, rather embarrassingly, after
months of reading through the code, in the end I only managed to submit a
patch after Simon told me exactly what I needed to do. Even more
depressingly, the other Simon (Marlow) was unhappy because it caused a
performance regression so the patch was rejected! Sad life..

In other words, I found the difficulty in actually being able to contribute
a meaningful patch is far greater than any difficulty in learning to use
the tools and process required to submit a patch.

Of course this is to be expected from a code base as large, old, and
complicated as GHC's, and I'm not too sure what can be done from a
technical standpoint to address this, besides better documentation. From a
process standpoint though, if I didn't have personal assistance from Simon
and Ben (Thank you!!!) I imagine I would have given up much sooner, despite
having been relatively motivated.

I don't know if this would be possible of course considering GHC developers
are very busy as it is, but it would be great if newcomers could be
assigned a mentor to contact when in need of help. Maybe I am just weird,
but I actually felt bad emailing everyone for help, so I would typically go
much longer than comfortable before asking for help. As you can imagine, as
the struggle increases, the likelihood of giving up also does, and I will
admit I thought about giving up many times.

I realize this would probably be difficult to scale, but hopefully as new
developers come, they would also be able to mentor others. I think this is
similar to what is done in the industry by many companies as well.

In summary, difficulty of understanding code base >>> difficulty of using
tools and following documentation.

On Sat, Sep 24, 2016 at 6:29 PM, Christopher Allen 
wrote:

> I'd be willing to help with work required to open up GHC development
> more along multiple lines including:
>
> Bots/automation for Github
>
> Talking to Rust devs about what works, what doesn't
>
> Talking to GHC devs about what works, what doesn't,
> comparing/contrasting with other processes such as Rust's
>
> Papering all this up into a "where we are, where we'd like to go" document
>
> Writing documentation and tutorials for getting new developers on board
>
> Manually on-boarding new developers
>
> I am willing to do this work in addition to my 9-5 work using Haskell,
> the book(s) which are a full-time job unto themselves, and the open
> source work I do.
>
> I will not do any of this as long as this is the attitude of GHC
> developers. I can not in good conscience encourage people to
> contribute to a project controlled and represented with such hostility
> and dismissiveness. The needs of the community and of new and casual
> contributors have to be taken seriously. This is not for their sake
> alone, it's to ease the workload of the maintainers and to mend the
> worsening culture gap.
>
>
> On Sat, Sep 24, 2016 at 8:19 PM, Brandon Allbery 
> wrote:
> >
> > On Sat, Sep 24, 2016 at 9:08 PM, Manuel M T Chakravarty
> >  wrote:
> >>
> >> Why are you so hostile to Chris? I don’t think that this is an
> appropriate
> >> way to treat somebody who is making a suggestion in good faith.
> >
> >
> > It may be in good faith. but it's not in good sense. There is a lot in
> the
> > background that made Rust's setup possible, and he's not bringing that to
> > the table, just assuming it'll somehow happen or that everyone else will
> > drop everything for the next few months and make it happen. And I feel
> like
> > he's being really pushy about committing already overworked people to
> this
> > --- and insisting that anyone opposed must have a hidden agenda or
> otherwise
> > cannot possibly have good reason to be opposed. It's not helpful at all;
> > it's basically a good way to stall ghc for the next few months at least.
> >
> > --
> > brandon s allbery kf8nh   sine nomine
> associates
> > allber...@gmail.com
> ballb...@sinenomine.net
> > unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>
>
>
> --
> Chris Allen
> Currently working on http://haske

Re: Notes from Ben's "contribute to ghc" discussion

[Christopher Allen]

I'd be willing to help with work required to open up GHC development
more along multiple lines including:

Bots/automation for Github

Talking to Rust devs about what works, what doesn't

Talking to GHC devs about what works, what doesn't,
comparing/contrasting with other processes such as Rust's

Papering all this up into a "where we are, where we'd like to go" document

Writing documentation and tutorials for getting new developers on board

Manually on-boarding new developers

I am willing to do this work in addition to my 9-5 work using Haskell,
the book(s) which are a full-time job unto themselves, and the open
source work I do.

I will not do any of this as long as this is the attitude of GHC
developers. I can not in good conscience encourage people to
contribute to a project controlled and represented with such hostility
and dismissiveness. The needs of the community and of new and casual
contributors have to be taken seriously. This is not for their sake
alone, it's to ease the workload of the maintainers and to mend the
worsening culture gap.


On Sat, Sep 24, 2016 at 8:19 PM, Brandon Allbery  wrote:
>
> On Sat, Sep 24, 2016 at 9:08 PM, Manuel M T Chakravarty
>  wrote:
>>
>> Why are you so hostile to Chris? I don’t think that this is an appropriate
>> way to treat somebody who is making a suggestion in good faith.
>
>
> It may be in good faith. but it's not in good sense. There is a lot in the
> background that made Rust's setup possible, and he's not bringing that to
> the table, just assuming it'll somehow happen or that everyone else will
> drop everything for the next few months and make it happen. And I feel like
> he's being really pushy about committing already overworked people to this
> --- and insisting that anyone opposed must have a hidden agenda or otherwise
> cannot possibly have good reason to be opposed. It's not helpful at all;
> it's basically a good way to stall ghc for the next few months at least.
>
> --
> brandon s allbery kf8nh   sine nomine associates
> allber...@gmail.com  ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net



-- 
Chris Allen
Currently working on http://haskellbook.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Notes from Ben's "contribute to ghc" discussion

[Brandon Allbery]

On Sat, Sep 24, 2016 at 9:08 PM, Manuel M T Chakravarty <
c...@justtesting.org> wrote:

> Why are you so hostile to Chris? I don’t think that this is an appropriate
> way to treat somebody who is making a suggestion in good faith.


It may be in good faith. but it's not in good sense. There is a lot in the
background that made Rust's setup possible, and he's not bringing that to
the table, just assuming it'll somehow happen or that everyone else will
drop everything for the next few months and make it happen. And I feel like
he's being really pushy about committing already overworked people to this
--- and insisting that anyone opposed must have a hidden agenda or
otherwise cannot possibly have good reason to be opposed. It's not helpful
at all; it's basically a good way to stall ghc for the next few months at
least.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Notes from Ben's "contribute to ghc" discussion

[Brandon Allbery]

On Sat, Sep 24, 2016 at 9:05 PM, Michael Sloan  wrote:

> As a side observer, I find Christopher's comments to be spot on.


They're missing quite a bit, actually. Like how Rust had a bunch of
contributors even before they started, and Mozilla Corp. backing them.
Rust's solution is only viable if someone wants to bring those to the table
along with it; it's just not possible otherwise. There aren't enough people
*now* to build a whole new infrastructure.

I work with another open source project that is as short on contributors as
ghc is. It's part of my day job, even, and it's a regular topic at team
meetings. One comes to understand why this is not something that can be
done on a whim. (And my employer isn't big enough to do the heavy lifting
or provide bodies --- even ignoring that we feel it's best for us and our
customers that this project remain independent, not controlled by or
beholden to any company, which makes contributing somewhat difficult as a
political matter although we do our best.)

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Notes from Ben's "contribute to ghc" discussion

[Manuel M T Chakravarty]

Why are you so hostile to Chris? I don’t think that this is an appropriate way 
to treat somebody who is making a suggestion in good faith.

Chris may not have contributed to GHC, but apart from co-authoring the 
currently most popular Haskell book, he has consistently contributed to helping 
people who are new to the language (on Slack, IRC, in blog posts, etc). He has 
suck a ton of time into moving the language forward.

Moreover, he knows a thing or two about helping newcomers in an effective 
manner. And he is right in his critique that it is hard to contribute to GHC.

For example, I recently wrote a patch concerning compatibility with macOS 
Sierra and even posted about it on this list:

  https://mail.haskell.org/pipermail/ghc-devs/2016-July/012512.html 


It’s a small patch, and I just don’t have the time to jump through all the 
hoops to get it into the repo.

And now before you accuse me of not having contributed to GHC, maybe check the 
git logs first.

In summary, if you don’t want to consider that maybe it is harder to contribute 
to GHC than it has to be and making it easier maybe would lead to more 
contributions, that is one thing. However, I do insist that suggestions made in 
good faith on this list are treated politely and not being brutally shot down.

Simon, I imagine you agree with me here.

Manuel

> Brandon Allbery :
> 
> 
> On Sat, Sep 24, 2016 at 8:38 PM, Christopher Allen  > wrote:
> This is so short-sighted and wrong that I don't think there's any
> point in my saying more. You've made it clear you don't care.
> 
> And --- note that I am not a ghc developer --- have made it clear that you do 
> not care how much extra work you make for already massively overworked ghc 
> developers.
> You're not contributing. You're not helping. You're derailing.
> 
> -- 
> brandon s allbery kf8nh   sine nomine associates
> allber...@gmail.com   
> ballb...@sinenomine.net 
> unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net 
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Notes from Ben's "contribute to ghc" discussion

[Michael Sloan]

As a side observer, I find Christopher's comments to be spot on.  My
lack of familiarity with phab has definitely de-railed my in-flight
patch, adding implicit parameter and recursive do support to Template
Haskell.  Certainly my own fault, but also induced by friction that
feels unnecessary.

On Sat, Sep 24, 2016 at 5:40 PM, Brandon Allbery  wrote:
>
> On Sat, Sep 24, 2016 at 8:38 PM, Christopher Allen 
> wrote:
>>
>> This is so short-sighted and wrong that I don't think there's any
>> point in my saying more. You've made it clear you don't care.
>
>
> And --- note that I am not a ghc developer --- have made it clear that you
> do not care how much extra work you make for already massively overworked
> ghc developers.
> You're not contributing. You're not helping. You're derailing.
>
> --
> brandon s allbery kf8nh   sine nomine associates
> allber...@gmail.com  ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Notes from Ben's "contribute to ghc" discussion

[Matthew Pickering]

It really is difficult to proceed when the problem is not well defined.

I also find it insulting that you suggest that I (and other
developers) don't care about bringing new users to the project. The
nebulous suggestion that GHC developers have ulterior motives is also
not becoming of a productive discussion.

There's clearly much more to be said but it seems pointless to proceed
any further.

Matt



On Sun, Sep 25, 2016 at 1:38 AM, Christopher Allen  wrote:
> My point is that at almost every level, contributing to GHC is a
> chore. Phabricator/Github is simply a good place to start for opening
> things up, but it's far from the only thing.
>
> http://www.arcadianvisions.com/blog/2016/ghc-contributing.html has the
> ring of verisimilitude to me and most working Haskellers I know. This
> bright line between the users of Haskell and the contributors to the
> primary compiler is not healthy long-term.
>
> The consistently dismissive attitude towards these objections is not
> good either.
>
> GHC has a very poor showing compared to other compilers with similar
> sets of users (FP, typed, or modern) in terms of onboarding new people
> and you won't take these critiques seriously. You do the bare minimum
> just so you can say you did something, but not substantive is open for
> discussion. This fools no-one!
>
>>I don't understand this fascination with Rust the Haskell community has. The 
>>two projects are very different. As you say in the post, GHC is a much older 
>>project and as a result has much less hype around it. Rust is the definition 
>>of a "hot new thing" and so it makes sense that there are more contributors.
>
> Hype draws consumers, not producers! Excellent process, documentation,
> and community is what turns those consumers into producers!
>
> This is so short-sighted and wrong that I don't think there's any
> point in my saying more. You've made it clear you don't care.
>
> On Sat, Sep 24, 2016 at 7:17 PM, Matthew Pickering
>  wrote:
>> I think this comment is useful because it highlights the point that it
>> isn't very clear what "the point" even is.
>>
>> Is the problem that the code review process happens on phabricator and
>> trac rather than github?
>> It seems unlikely the project will move to github, phabricator works
>> well for existing developers. In fact, phabricator was the best thing
>> to ever happen to increase accessibility to newcomers. Thomie create
>> some stats about the new contributors and there was a large spike
>> after the more to phab.
>>
>> Is the problem that the way which new features are proposed is opaque?
>> Ben worked on a new proposals process to help with this -
>> https://github.com/ghc-proposals/ghc-proposals
>>
>> Is the problem technical? Is the build system not suitable? Is the
>> code base poorly organised?
>> This should be said but ultimately the project is a volunteer based
>> effort. People don't like spending their time doing refactoring. It
>> would take someone
>> who particularly cared about newcomer contributors to do some of the
>> cleanup work.
>>
>> Ultimately, I'm not sure what exactly what the point is. I read posts
>> like this ( http://www.arcadianvisions.com/blog/2016/ghc-contributing.html
>> ) and find myself disagreeing with almost every point. The comments in
>> the reddit thread provide most of the refutations. The post doesn't
>> address the
>> fact that the feature was a small syntactic change which as erik
>> pointed out, it perhaps the most difficult change to integrate as it
>> must certainly pay it's way.
>>
>> Contributing to any project requires a certain amount of investment.
>> Empirically, it seems to me that
>> if the user makes the investment to build GHC and fix an issue then
>> the last step, setting up phabricator,
>> is not a point of friction. There are good instructions on the wiki
>> which describe this process. Recently I have witnessed a new
>> contributor independently provide a patch and
>> when prompted to submit to phabricator, did so within a few hours.
>> Phabricator doesn't seem to be a serious issue.
>>
>> Could you perhaps point to some concrete examples of people who have
>> tried to contribute and where the sticking points are?
>> As you observe, we are well meaning with this list but not very well
>> placed to solve this problem as it is not clear even if there
>> is a problem to solve and if there is, what the *exact* problem is.
>>
>> At the end of the day it is the core contributors who contribute the
>> most code so the process should be optimised for them. As you probably
>> read in my last email,
>> phabricator works well for me but I am interested in helping newcomers
>> get involved in the project. I think the best way to do this is
>> managing the issue tracker well and providing 1-1 personal assistance
>> to people when they need it. After a few patches, it gets much easier.
>>
>> If this comment makes no sense to you, then it would be even more
>> beneficial if you could explain to me h

Re: Notes from Ben's "contribute to ghc" discussion

[Brandon Allbery]

On Sat, Sep 24, 2016 at 8:38 PM, Christopher Allen 
wrote:

> This is so short-sighted and wrong that I don't think there's any
> point in my saying more. You've made it clear you don't care.
>

And --- note that I am not a ghc developer --- have made it clear that you
do not care how much extra work you make for already massively overworked
ghc developers.
You're not contributing. You're not helping. You're derailing.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Notes from Ben's "contribute to ghc" discussion

[Christopher Allen]

My point is that at almost every level, contributing to GHC is a
chore. Phabricator/Github is simply a good place to start for opening
things up, but it's far from the only thing.

http://www.arcadianvisions.com/blog/2016/ghc-contributing.html has the
ring of verisimilitude to me and most working Haskellers I know. This
bright line between the users of Haskell and the contributors to the
primary compiler is not healthy long-term.

The consistently dismissive attitude towards these objections is not
good either.

GHC has a very poor showing compared to other compilers with similar
sets of users (FP, typed, or modern) in terms of onboarding new people
and you won't take these critiques seriously. You do the bare minimum
just so you can say you did something, but not substantive is open for
discussion. This fools no-one!

>I don't understand this fascination with Rust the Haskell community has. The 
>two projects are very different. As you say in the post, GHC is a much older 
>project and as a result has much less hype around it. Rust is the definition 
>of a "hot new thing" and so it makes sense that there are more contributors.

Hype draws consumers, not producers! Excellent process, documentation,
and community is what turns those consumers into producers!

This is so short-sighted and wrong that I don't think there's any
point in my saying more. You've made it clear you don't care.

On Sat, Sep 24, 2016 at 7:17 PM, Matthew Pickering
 wrote:
> I think this comment is useful because it highlights the point that it
> isn't very clear what "the point" even is.
>
> Is the problem that the code review process happens on phabricator and
> trac rather than github?
> It seems unlikely the project will move to github, phabricator works
> well for existing developers. In fact, phabricator was the best thing
> to ever happen to increase accessibility to newcomers. Thomie create
> some stats about the new contributors and there was a large spike
> after the more to phab.
>
> Is the problem that the way which new features are proposed is opaque?
> Ben worked on a new proposals process to help with this -
> https://github.com/ghc-proposals/ghc-proposals
>
> Is the problem technical? Is the build system not suitable? Is the
> code base poorly organised?
> This should be said but ultimately the project is a volunteer based
> effort. People don't like spending their time doing refactoring. It
> would take someone
> who particularly cared about newcomer contributors to do some of the
> cleanup work.
>
> Ultimately, I'm not sure what exactly what the point is. I read posts
> like this ( http://www.arcadianvisions.com/blog/2016/ghc-contributing.html
> ) and find myself disagreeing with almost every point. The comments in
> the reddit thread provide most of the refutations. The post doesn't
> address the
> fact that the feature was a small syntactic change which as erik
> pointed out, it perhaps the most difficult change to integrate as it
> must certainly pay it's way.
>
> Contributing to any project requires a certain amount of investment.
> Empirically, it seems to me that
> if the user makes the investment to build GHC and fix an issue then
> the last step, setting up phabricator,
> is not a point of friction. There are good instructions on the wiki
> which describe this process. Recently I have witnessed a new
> contributor independently provide a patch and
> when prompted to submit to phabricator, did so within a few hours.
> Phabricator doesn't seem to be a serious issue.
>
> Could you perhaps point to some concrete examples of people who have
> tried to contribute and where the sticking points are?
> As you observe, we are well meaning with this list but not very well
> placed to solve this problem as it is not clear even if there
> is a problem to solve and if there is, what the *exact* problem is.
>
> At the end of the day it is the core contributors who contribute the
> most code so the process should be optimised for them. As you probably
> read in my last email,
> phabricator works well for me but I am interested in helping newcomers
> get involved in the project. I think the best way to do this is
> managing the issue tracker well and providing 1-1 personal assistance
> to people when they need it. After a few patches, it gets much easier.
>
> If this comment makes no sense to you, then it would be even more
> beneficial if you could explain to me how other people perceive the
> process.
>
> Matt
>
> On Sun, Sep 25, 2016 at 12:36 AM, Christopher Allen  
> wrote:
>>>I think the we'd want to restrict this to Diffs submitted by contributors 
>>>who already possess commit bits and specifically include a "no-review" tag 
>>>in the summary.
>>
>> Is this intended to address the issues new contributors have in
>> contributing to GHC? This looks more insider stuff that misses the
>> point if so.
>>
>> If new contributors are not part of a conversation about contributing
>> to GHC, when and where did that conversation ha

Re: Notes from Ben's "contribute to ghc" discussion

[Matthew Pickering]

I don't understand this fascination with Rust the Haskell community
has. The two projects are very different. As you say in the post, GHC
is a much older project and as a result has much less hype around it.
Rust is the definition of a "hot new thing" and so it makes sense that
there are more contributors. I am sure that github contributes to some
contributors but this discussion is pointless unless this common
assertion is put into context.

Not only this but mozilla has many more full-time rust developers to
facilitate the process. I couldn't find the exact number so I will
avoid quoting it but GHC has only 1 full time developer. This is a
significant increase in man power and also leaves time for the ability
to more closely manage and cultivate the community of contributors. We
don't have that luxury.

You also say why github is an unsuitable tool for such a project. The
fact that they have had to develop their own sophisticated bots in
order to deal with the issue tracker is just indicative that github
doesn't provide the flexibility necessary. The new projects interface
does look more promising but it is lightyears behind what phab
provides. Github is good for small projects as the interface is
optimised for them but I don't believe that it scales well.

The essential argument seems to be that moving to github would "solve
all the problems with GHC development" but its seems to be based on
false premises. In order for this discussion to move forward it seems
that we could all do with vocalising the issues that we perceive to
make sure that we're all working on the same page. It doesn't appear
to be the case at the moment.

And some comments inline:

> I work with someone that has contributed to GHCJS more than once, but
> will not go anywhere near GHC. This is almost entirely because of the
> opaque process.

What is opaque about the process? What does he want to contribute but
feels unable to?

> Putting aside Github's new code review functionality (which seems fine
> but isn't anything terribly impressive), there are lots of ways to
> skin the code review cat without putting new contributors in a
> typo-fix PR ghetto.

What does this comment mean? What is a "type-fix PR ghetto"?

It seems that you are suggesting moving to github but then using a
different service to do code review?

Matt
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Notes from Ben's "contribute to ghc" discussion

[Brandon Allbery]

On Sat, Sep 24, 2016 at 8:17 PM, Christopher Allen 
wrote:

> They don't rely on bare Github, they use bots to automate and add
> structure in the ways you're trying to wring out of Phabricator.
>

Other way around: they, and pretty much every large project, are forced to
invent their own bots and automation to wring some usability out of
github's minimal functionality. Which is why other large projects use
phabricator, gerrit, etc. instead of dumping a massive amount of effort
into trying to make github do what they need.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Notes from Ben's "contribute to ghc" discussion

[Matthew Pickering]

I think this comment is useful because it highlights the point that it
isn't very clear what "the point" even is.

Is the problem that the code review process happens on phabricator and
trac rather than github?
It seems unlikely the project will move to github, phabricator works
well for existing developers. In fact, phabricator was the best thing
to ever happen to increase accessibility to newcomers. Thomie create
some stats about the new contributors and there was a large spike
after the more to phab.

Is the problem that the way which new features are proposed is opaque?
Ben worked on a new proposals process to help with this -
https://github.com/ghc-proposals/ghc-proposals

Is the problem technical? Is the build system not suitable? Is the
code base poorly organised?
This should be said but ultimately the project is a volunteer based
effort. People don't like spending their time doing refactoring. It
would take someone
who particularly cared about newcomer contributors to do some of the
cleanup work.

Ultimately, I'm not sure what exactly what the point is. I read posts
like this ( http://www.arcadianvisions.com/blog/2016/ghc-contributing.html
) and find myself disagreeing with almost every point. The comments in
the reddit thread provide most of the refutations. The post doesn't
address the
fact that the feature was a small syntactic change which as erik
pointed out, it perhaps the most difficult change to integrate as it
must certainly pay it's way.

Contributing to any project requires a certain amount of investment.
Empirically, it seems to me that
if the user makes the investment to build GHC and fix an issue then
the last step, setting up phabricator,
is not a point of friction. There are good instructions on the wiki
which describe this process. Recently I have witnessed a new
contributor independently provide a patch and
when prompted to submit to phabricator, did so within a few hours.
Phabricator doesn't seem to be a serious issue.

Could you perhaps point to some concrete examples of people who have
tried to contribute and where the sticking points are?
As you observe, we are well meaning with this list but not very well
placed to solve this problem as it is not clear even if there
is a problem to solve and if there is, what the *exact* problem is.

At the end of the day it is the core contributors who contribute the
most code so the process should be optimised for them. As you probably
read in my last email,
phabricator works well for me but I am interested in helping newcomers
get involved in the project. I think the best way to do this is
managing the issue tracker well and providing 1-1 personal assistance
to people when they need it. After a few patches, it gets much easier.

If this comment makes no sense to you, then it would be even more
beneficial if you could explain to me how other people perceive the
process.

Matt

On Sun, Sep 25, 2016 at 12:36 AM, Christopher Allen  wrote:
>>I think the we'd want to restrict this to Diffs submitted by contributors who 
>>already possess commit bits and specifically include a "no-review" tag in the 
>>summary.
>
> Is this intended to address the issues new contributors have in
> contributing to GHC? This looks more insider stuff that misses the
> point if so.
>
> If new contributors are not part of a conversation about contributing
> to GHC, when and where did that conversation happen and what is being
> done about it?
>
> On Sat, Sep 24, 2016 at 4:37 PM, Ben Gamari  wrote:
>> Phyx  writes:
>>
>
> ·Auto-push: Ability to push to Phab and have it committed
> automatically if it validates.

 \o/
>>>
>>> How would this work? Could there be a cooldown period? e.g. commits sit a
>>> day before being auto-committed?
>>>
>>> Validate really only validates Linux x86_64. The situation is already quite
>>> dire for other architectures and OSes,
>>> I fear making it worse by not allowing people time to object.
>>>
>> The solution here is to extend Harbormaster coverage, which is on my
>> list anyways. My priorities is roughly,
>>
>>> Would this be a per person setting? This just raises so many questions. And
>>> I don't quite see what problem it's solving
>>> because presumably code is tested before it's put on Phab isn't it?
>>
>> I think the we'd want to restrict this to Diffs submitted by
>> contributors who already possess commit bits and specifically include a
>> "no-review" tag in the summary. The idea here is to provide an
>> alternative to pushing directly to master, extending the coverage of
>> Harbormaster without inconveniencing contributors.
>>
>> Cheers,
>>
>> - Ben
>>
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>
>
>
> --
> Chris Allen
> Currently working on http://haskellbook.com
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.

Re: Notes from Ben's "contribute to ghc" discussion

[Christopher Allen]

Why are contributions via Github limited to things that don't require
review? That won't encourage anyone to get started because they know
that as soon as they move on to something substantive, they'll hit the
same brick wall. You can't boil a frog by taking it out of the pot of
lukewarm water and tossing it into the roiling kettle.

Have you looked at how Rust handles contributions to the compiler?

https://github.com/rust-lang/rust

They don't rely on bare Github, they use bots to automate and add
structure in the ways you're trying to wring out of Phabricator.

The automation and community they've built here is above and beyond
anything I've seen in any other community, it is _outstanding_ and it
behooves us to learn what they do and to take it seriously. Rust has
five times the contributors GHC does and the depth of contributions do
not trail off as quickly.

Rust has been around for less time than many popular Haskell libraries!

To see more of how Rust developers and users discuss new features and
improvements, this forum is illuminating:
https://internals.rust-lang.org/

I work with someone that has contributed to GHCJS more than once, but
will not go anywhere near GHC. This is almost entirely because of the
opaque process.

Another: https://github.com/purescript/purescript

94 contributors, only a couple years old, written in Haskell but has
many users who came from JS and don't know any Haskell, used mostly
for frontend work.

Putting aside Github's new code review functionality (which seems fine
but isn't anything terribly impressive), there are lots of ways to
skin the code review cat without putting new contributors in a
typo-fix PR ghetto.


On Sat, Sep 24, 2016 at 6:53 PM, Joachim Breitner
 wrote:
> Hi,
>
> Am Samstag, den 24.09.2016, 18:46 -0500 schrieb Christopher Allen:
>> Seems reasonable, but much of the consternation over GHC dev process
>> has been about the relative illegibility of it, even for working
>> programmers who've hacked on compilers before. It's concerning to see
>> a list of items about a "contribute to GHC" discussion that seemingly
>> includes nothing that addresses this.
>>
>> Can you point me to any discussions among GHC devs on this since the
>> last time it was raised?
>
> I’m not sure why this proposal is causing unease here? Regular
> contributors are contributors too!
>
> Also, the idea of accepting trivial commits via GitHub (which are then
> pushed by someone with commit access) works much better if the latter
> can be done efficient, i.e. in a fire-and-forget, but still safe and
> checked, mode.
>
> And the list does include a few things that are meant to help new
> contributors:
>  * Accepting contributions where a quick review suffices via
>GitHub (that’s the item “lightweight pushes”).
>  * Not imposing style guides that people have to learn first
>  * Docker images to quickly get started.
>  * Easier ways of learning about GHC development (by removing old docs,
>and leverating SO).
>
> That list is not meant to be exhaustive, if you have other ideas how to
> make GHC hacking more accessible, please tell us!
>
> I am under the impression that there is some misunderstanding here,
> because there really is nothing not be wound up about here.
>
> Greetings,
> Joachim
>
>
>
> --
> Joachim “nomeata” Breitner
>   m...@joachim-breitner.de • https://www.joachim-breitner.de/
>   XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
>   Debian Developer: nome...@debian.org
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>



-- 
Chris Allen
Currently working on http://haskellbook.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Notes from Ben's "contribute to ghc" discussion

[Joachim Breitner]

Hi,

Am Samstag, den 24.09.2016, 18:46 -0500 schrieb Christopher Allen:
> Seems reasonable, but much of the consternation over GHC dev process
> has been about the relative illegibility of it, even for working
> programmers who've hacked on compilers before. It's concerning to see
> a list of items about a "contribute to GHC" discussion that seemingly
> includes nothing that addresses this.
> 
> Can you point me to any discussions among GHC devs on this since the
> last time it was raised?

I’m not sure why this proposal is causing unease here? Regular
contributors are contributors too!

Also, the idea of accepting trivial commits via GitHub (which are then
pushed by someone with commit access) works much better if the latter
can be done efficient, i.e. in a fire-and-forget, but still safe and
checked, mode.

And the list does include a few things that are meant to help new
contributors:
 * Accepting contributions where a quick review suffices via 
   GitHub (that’s the item “lightweight pushes”).
 * Not imposing style guides that people have to learn first
 * Docker images to quickly get started.
 * Easier ways of learning about GHC development (by removing old docs,
   and leverating SO).

That list is not meant to be exhaustive, if you have other ideas how to
make GHC hacking more accessible, please tell us!

I am under the impression that there is some misunderstanding here,
because there really is nothing not be wound up about here.

Greetings,
Joachim



-- 
Joachim “nomeata” Breitner
  m...@joachim-breitner.de • https://www.joachim-breitner.de/
  XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: nome...@debian.org

signature.asc
Description: This is a digitally signed message part
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Notes from Ben's "contribute to ghc" discussion

[Christopher Allen]

Seems reasonable, but much of the consternation over GHC dev process
has been about the relative illegibility of it, even for working
programmers who've hacked on compilers before. It's concerning to see
a list of items about a "contribute to GHC" discussion that seemingly
includes nothing that addresses this.

Can you point me to any discussions among GHC devs on this since the
last time it was raised?

On Sat, Sep 24, 2016 at 6:41 PM, Joachim Breitner
 wrote:
> Hi,
>
> Am Samstag, den 24.09.2016, 18:36 -0500 schrieb Christopher Allen:
>> >
>> > I think the we'd want to restrict this to Diffs submitted by
>> > contributors who already possess commit bits and specifically
>> > include a "no-review" tag in the summary.
>>
>> Is this intended to address the issues new contributors have in
>> contributing to GHC? This looks more insider stuff that misses the
>> point if so.
>>
>> If new contributors are not part of a conversation about contributing
>> to GHC, when and where did that conversation happen and what is being
>> done about it?
>
> Let me clarify: The auto-commit-after-build feature is completely
> unrelated to new contributors, and purely a way to reduce friction for
> regular contributors.
>
> (But everyone benefits as the repo is broken less often with such a
> feature at our fingertips.)
>
> Greetings,
> Joachim
>
>
> --
> Joachim “nomeata” Breitner
>   m...@joachim-breitner.de • https://www.joachim-breitner.de/
>   XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
>   Debian Developer: nome...@debian.org
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>



-- 
Chris Allen
Currently working on http://haskellbook.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Notes from Ben's "contribute to ghc" discussion

[Joachim Breitner]

Hi,

Am Samstag, den 24.09.2016, 18:36 -0500 schrieb Christopher Allen:
> > 
> > I think the we'd want to restrict this to Diffs submitted by
> > contributors who already possess commit bits and specifically
> > include a "no-review" tag in the summary.
> 
> Is this intended to address the issues new contributors have in
> contributing to GHC? This looks more insider stuff that misses the
> point if so.
> 
> If new contributors are not part of a conversation about contributing
> to GHC, when and where did that conversation happen and what is being
> done about it?

Let me clarify: The auto-commit-after-build feature is completely
unrelated to new contributors, and purely a way to reduce friction for
regular contributors.

(But everyone benefits as the repo is broken less often with such a
feature at our fingertips.)

Greetings,
Joachim


-- 
Joachim “nomeata” Breitner
  m...@joachim-breitner.de • https://www.joachim-breitner.de/
  XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: nome...@debian.org

signature.asc
Description: This is a digitally signed message part
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Notes from Ben's "contribute to ghc" discussion

[Christopher Allen]

>I think the we'd want to restrict this to Diffs submitted by contributors who 
>already possess commit bits and specifically include a "no-review" tag in the 
>summary.

Is this intended to address the issues new contributors have in
contributing to GHC? This looks more insider stuff that misses the
point if so.

If new contributors are not part of a conversation about contributing
to GHC, when and where did that conversation happen and what is being
done about it?

On Sat, Sep 24, 2016 at 4:37 PM, Ben Gamari  wrote:
> Phyx  writes:
>

 ·Auto-push: Ability to push to Phab and have it committed
 automatically if it validates.
>>>
>>> \o/
>>
>> How would this work? Could there be a cooldown period? e.g. commits sit a
>> day before being auto-committed?
>>
>> Validate really only validates Linux x86_64. The situation is already quite
>> dire for other architectures and OSes,
>> I fear making it worse by not allowing people time to object.
>>
> The solution here is to extend Harbormaster coverage, which is on my
> list anyways. My priorities is roughly,
>
>> Would this be a per person setting? This just raises so many questions. And
>> I don't quite see what problem it's solving
>> because presumably code is tested before it's put on Phab isn't it?
>
> I think the we'd want to restrict this to Diffs submitted by
> contributors who already possess commit bits and specifically include a
> "no-review" tag in the summary. The idea here is to provide an
> alternative to pushing directly to master, extending the coverage of
> Harbormaster without inconveniencing contributors.
>
> Cheers,
>
> - Ben
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>



-- 
Chris Allen
Currently working on http://haskellbook.com
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Notes from Ben's "contribute to ghc" discussion

[Matthew Pickering]

There is a phabricator module, ponder [1], which looks suitable for
the Q&A feature. Surely we all agree that it is easier to setup this
module than to host a completely separate service ourselves! This also
has the advantage of being able to reference commits, differentials
and tickets in an easy manner.

Another question about administration, it doesn't seem like many
people have permissions to modify the phabricator installation. How
easy is it to give some people more elevated positions to deal with
things like updating the home page, giving badges, moderating "ponder"
and so on? The homepage hasn't been updated for quite a while, the
"recent events" tab makes it look like the project is quite dead.

If anyone has ever talked to me about this, it should be clear that I
am a massive phabricator fanboy and think that we should utilise it
more. There are lots of modules [2] that we don't use and the product
is just going to get better as other companies (ie facebook) continue
to drive it. I think that in the future it would be beneficial to port
the wiki and bug tracker from trac to the corresponding phabricator
features, phriction and maniphest respectively. Firstly, I think
phabricator is just better than trac but the primary reason is that
trac is not very actively developed.

So three separate thoughts in this email, only one of which is
relevant to the thread. With regards to the other points in Simon's
email, I don't feel qualified to opine too much as GHC is the only
"large" project I have contributed to. Bear that in mind when reading
my comments inline below. I'll make sure to check out the video when
it is released as well.

[1]: https://secure.phabricator.com/ponder/
[2]: https://secure.phabricator.com/w/starmap/

> ·Doc bugs.Two kinds
>
> o   Typos.   Friction stops me
>
> o   Explanations needed e.g. read/show

The biggest friction is the fact some of the user guide is generated
so you have to build the whole compiler to build the user guide. It
seems like it would be possible to
just not include this generated section if you wanted to compile the
guide in order to check you didn't make a syntax mistake or something.
Perhaps it would be good if the build bots made the generated user
guide available for each build it did. I don't know how feasible this
is.

>
> ·Lightweight pushes

What does this mean?

>
> ·Make user manual into its own repo, to make it easier to take pull
> requests.  But that makes it harder when making synchronised changes to GHC
> and user manual.

Submodules are annoying to update, everyone knows this. Separating out
the two makes synchronous updates harder to review together but makes
drive-by updates easier. I think it would be nice if there was a
web-interface which allowed people to edit the user guide in the
browser rather than have to setup an entire development environment.

>
> ·Auto-push: Ability to push to Phab and have it committed
> automatically if it validates.

This seems like a reasonable idea but perhaps not worth the effort
needed to set it up. My usual workflow is to put most of my commits
onto phabrictor with the thought that
it's better for less people to directly interact with the main branch.
If Ben would prefer less control then I can merge more things myself
without issues!

>
> ·Style guides.  Is having a defined style solving a problem we don’t
> really have?  One piece of guidance: adhere to the style of the surrounding
> code.  Low priority.

I think a consistent style wouldn't be a bad thing. The code is a bit
strange as Simon perfers the semi-colon style which not many people
other than him in the whole community
uses. The more pressing concern to me is the scale of the API to some
modules is very large, there are lots of exposed functions which
aren't documented at all which do slightly different things with
subtle invariants. A much more beneficial change would be to enforce
that new library style functions should get haddock comments saying
what they do! Cutting back these APIs is hard as it requires a very
good knowledge of the compiler which not many people have.



> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Notes from Ben's "contribute to ghc" discussion

[Ben Gamari]

Phyx  writes:

>>>
>>> ·Auto-push: Ability to push to Phab and have it committed
>>> automatically if it validates.
>>
>> \o/
>
> How would this work? Could there be a cooldown period? e.g. commits sit a
> day before being auto-committed?
>
> Validate really only validates Linux x86_64. The situation is already quite
> dire for other architectures and OSes,
> I fear making it worse by not allowing people time to object.
>
The solution here is to extend Harbormaster coverage, which is on my
list anyways. My priorities is roughly,

> Would this be a per person setting? This just raises so many questions. And
> I don't quite see what problem it's solving
> because presumably code is tested before it's put on Phab isn't it?

I think the we'd want to restrict this to Diffs submitted by
contributors who already possess commit bits and specifically include a
"no-review" tag in the summary. The idea here is to provide an
alternative to pushing directly to master, extending the coverage of
Harbormaster without inconveniencing contributors.

Cheers,

- Ben


signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Notes from Ben's "contribute to ghc" discussion

[Ben Gamari]

Joachim Breitner  writes:

> Hi,
>
Thanks everyone for your comments, and to Simon for collecting these
notes.

> I’ll add some notes to extend the discussion to the mailing list.
>
> Am Samstag, den 24.09.2016, 01:44 + schrieb Simon Peyton Jones via
> ghc-devs:
>> 
>> ·    Make user manual into its own repo, to make it easier to
>> take pull requests.  But that makes it harder when making
>> synchronised changes to GHC and user manual.
>
> I don’t think we need a separate repo in order to allow contributors to
> easily build the manual on its own, and to accept contributions to via
> GitHub.
>
The only slightly tricky part here is the users guide parts generated by
utils/mkUserGuidePart. This is currently built by stage1, but strictly
speaking there's no reason why it couldn't be built with stage0.
>> 
>> ·    Auto-push: Ability to push to Phab and have it committed
>> automatically if it validates.
>
I'll look into how we might be able to accomplish this.

Cheers,

- Ben


signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Notes from Ben's "contribute to ghc" discussion

[Phyx]

>>
>> ·Auto-push: Ability to push to Phab and have it committed
>> automatically if it validates.
>
> \o/

How would this work? Could there be a cooldown period? e.g. commits sit a
day before being auto-committed?

Validate really only validates Linux x86_64. The situation is already quite
dire for other architectures and OSes,
I fear making it worse by not allowing people time to object.

Would this be a per person setting? This just raises so many questions. And
I don't quite see what problem it's solving
because presumably code is tested before it's put on Phab isn't it?
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Notes from Ben's "contribute to ghc" discussion

[Eric Seidel]

On Fri, Sep 23, 2016, at 23:46, Joachim Breitner wrote:
> Any reason not to use http://stackoverflow.com/?

That would certainly be the easiest solution. The questions that occur
to me are:

1. Do GHC-dev questions fit within the purview of StackOverflow? I think
   so, there are plenty of library-specific questions on SO, so
   questions like "what's the best way to lookup a Name?" ought to be in
   scope. But maybe there are other kinds of questions (not specifically
   programming-related) that we'd like to collect answers to. If that's
   the case the SO mods might close those other questions as off-topic.

2. Do we want to exercise more control over the GHC Q&A site than a tag
   on SO would allow? We do host a lot of infrastructure ourselves and I
   assume there are good reasons for that.

Eric
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Notes from Ben's "contribute to ghc" discussion

[Joachim Breitner]

Hi,

I’ll add some notes to extend the discussion to the mailing list.

Am Samstag, den 24.09.2016, 01:44 + schrieb Simon Peyton Jones via
ghc-devs:
> 
> ·    Make user manual into its own repo, to make it easier to
> take pull requests.  But that makes it harder when making
> synchronised changes to GHC and user manual.

I don’t think we need a separate repo in order to allow contributors to
easily build the manual on its own, and to accept contributions to via
GitHub.

> 
> ·    Auto-push: Ability to push to Phab and have it committed
> automatically if it validates.

\o/

> 
> ·    Have a GHC StackOverflow on haskell.org   (Jacob Zalewski
> jakz...@gmail.com offers to do this! – thank you).  It has a useful
> new Documentation feature.   Eg this would be good for “how do I look
> up a RdrName to get a Name… there seem to be six different functions
> that do that”.

Any reason not to use http://stackoverflow.com/?

Greetings,
Joachim
-- 
Joachim “nomeata” Breitner
  m...@joachim-breitner.de • https://www.joachim-breitner.de/
  XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: nome...@debian.org

signature.asc
Description: This is a digitally signed message part
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Notes from Ben's "contribute to ghc" discussion

[Eric Seidel]

I found a list of StackOverflow clones. (I don't know how difficult it
is to get an official StackExchange site, or if we would even want that)

http://meta.stackexchange.com/questions/2267/stack-exchange-clones


On Fri, Sep 23, 2016, at 18:44, Simon Peyton Jones via ghc-devs wrote:
> Friends
>
> Here are the notes I took from session 2 of the Haskell Implementors
> Meeting.  The bolding is my choice of emphasis.
>
> Simon
>
>
> *Doc bugs.Two kinds
>
> o   Typos.   Friction stops me
>
> o   Explanations needed e.g. read/show
>
> *Lightweight pushes
>
> *Make user manual into its own repo, to make it easier to take
> pull requests.  But that makes it harder when making
> synchronised changes
> to GHC and user manual.
>
> *Auto-push: Ability to push to Phab and have it committed
> automatically if it validates.
>
> *Style guides.  Is having a defined style solving a problem we
> don't really have?  One piece of guidance: adhere to the style of the
> surrounding code.  Low priority.
>
> *Docker images.   We should have one.
>
> *Remove old documentation!
>
> *Cross compilation is difficult.
>
> *Have a GHC StackOverflow on haskell.org   (Jacob Zalewski
> jakz...@gmail.com offers to do this! - thank
> you).  It has a useful new Documentation feature.   Eg this
> would be good
> for "how do I look up a RdrName to get a Name... there seem to be six
> different functions that do that".
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs