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
|

Notes from Ben's "contribute to ghc" discussion

GHC - devs mailing list

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
Reply | Threaded
Open this post in threaded view
|

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

Eric Seidel-3
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)



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
> [hidden email]<mailto:[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
> 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

Joachim Breitner-2
In reply to this post by GHC - devs mailing list
Hi,

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

Am Samstag, den 24.09.2016, 01:44 +0000 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
> [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”.

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

Greetings,
Joachim
--
Joachim “nomeata” Breitner
  [hidden email]https://www.joachim-breitner.de/
  XMPP: [hidden email] • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: [hidden email]
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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

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

Eric Seidel-3
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
[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

Phyx
In reply to this post by Joachim Breitner-2
>>
>> ·        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
[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 Joachim Breitner-2
Joachim Breitner <[hidden email]> 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 +0000 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

_______________________________________________
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 Phyx
Phyx <[hidden email]> 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
[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

Matthew Pickering
In reply to this post by GHC - devs mailing list
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
> [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

Christopher Allen
In reply to this post by Ben Gamari-2
>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 <[hidden email]> wrote:

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



--
Chris Allen
Currently working on http://haskellbook.com
_______________________________________________
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

Joachim Breitner-2
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
  [hidden email]https://www.joachim-breitner.de/
  XMPP: [hidden email] • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: [hidden email]
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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

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
<[hidden email]> 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
>   [hidden email]https://www.joachim-breitner.de/
>   XMPP: [hidden email] • OpenPGP-Key: 0xF0FBF51F
>   Debian Developer: [hidden email]
>
> _______________________________________________
> ghc-devs mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>



--
Chris Allen
Currently working on http://haskellbook.com
_______________________________________________
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

Joachim Breitner-2
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
  [hidden email]https://www.joachim-breitner.de/
  XMPP: [hidden email] • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: [hidden email]
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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

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
<[hidden email]> 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
>   [hidden email]https://www.joachim-breitner.de/
>   XMPP: [hidden email] • OpenPGP-Key: 0xF0FBF51F
>   Debian Developer: [hidden email]
>
> _______________________________________________
> ghc-devs mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>



--
Chris Allen
Currently working on http://haskellbook.com
_______________________________________________
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

Matthew Pickering
In reply to this post by Christopher Allen
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 <[hidden email]> 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 <[hidden email]> wrote:
>> Phyx <[hidden email]> 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
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>
>
>
> --
> Chris Allen
> Currently working on http://haskellbook.com
> _______________________________________________
> 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

Brandon Allbery
In reply to this post by Christopher Allen

On Sat, Sep 24, 2016 at 8:17 PM, Christopher Allen <[hidden email]> 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
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
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

Matthew Pickering
In reply to this post by Christopher Allen
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
[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

Christopher Allen
In reply to this post by Matthew Pickering
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
<[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>>> Phyx <[hidden email]> 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
>>> [hidden email]
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>
>>
>>
>>
>> --
>> Chris Allen
>> Currently working on http://haskellbook.com
>> _______________________________________________
>> ghc-devs mailing list
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



--
Chris Allen
Currently working on http://haskellbook.com
_______________________________________________
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

Brandon Allbery

On Sat, Sep 24, 2016 at 8:38 PM, Christopher Allen <[hidden email]> 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
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
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

Matthew Pickering
In reply to this post by Christopher Allen
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 <[hidden email]> 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
> <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>>>> Phyx <[hidden email]> 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
>>>> [hidden email]
>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>>
>>>
>>>
>>>
>>> --
>>> Chris Allen
>>> Currently working on http://haskellbook.com
>>> _______________________________________________
>>> ghc-devs mailing list
>>> [hidden email]
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
>
> --
> Chris Allen
> Currently working on http://haskellbook.com
_______________________________________________
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
In reply to this post by Brandon Allbery
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 <[hidden email]> wrote:

>
> On Sat, Sep 24, 2016 at 8:38 PM, Christopher Allen <[hidden email]>
> 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
> [hidden email]                                  [hidden email]
> unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
>
> _______________________________________________
> 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