Notes from Ben's "contribute to ghc" discussion

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
50 messages Options
123
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> wrote:
Simon Marlow <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

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

Simon Marlow-7
In reply to this post by Ben Gamari-2
On 26 September 2016 at 20:13, Ben Gamari <[hidden email]> wrote:
Simon Marlow <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

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

Michael Sloan
On Mon, Sep 26, 2016 at 12:40 PM, Simon Marlow <[hidden email]> wrote:

> On 26 September 2016 at 20:13, Ben Gamari <[hidden email]> wrote:
>>
>> Simon Marlow <[hidden email]> 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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

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

Ben Gamari-2
In reply to this post by Richard Fung
Richard Fung <[hidden email]> 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

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (482 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Ben Gamari-2
In reply to this post by Simon Marlow-7
Simon Marlow <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (482 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> wrote:
Simon Marlow <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

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

Simon Marlow-7
In reply to this post by Ben Gamari-2
On 26 September 2016 at 22:51, Ben Gamari <[hidden email]> wrote:
Simon Marlow <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

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

GHC - devs mailing list
In reply to this post by Brandon Allbery
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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

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

Alexander Vershilov
In reply to this post by GHC - devs mailing list
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
<[hidden email]> 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
> [hidden email] 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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>



--
Alexander
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

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

Michael Sloan
On Tue, Sep 27, 2016 at 8:20 AM, Alexander V Vershilov
<[hidden email]> 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
> <[hidden email]> 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
>> [hidden email] 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
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>
>
>
> --
> Alexander
> _______________________________________________
> ghc-devs mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
123