...

· 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?

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

Is this intended to address the issues new contributors have in contributing to GHC? This looks more insider stuff that misses the point if so. If new contributors are not part of a conversation about contributing to GHC, when and where did that conversation happen and what is being done about it? On Sat, Sep 24, 2016 at 4:37 PM, Ben Gamari wrote:

Phyx writes:

...

...

...

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

\o/

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

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

The solution here is to extend Harbormaster coverage, which is on my list anyways. My priorities is roughly,

...

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

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

Cheers,

- Ben

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

-- Chris Allen Currently working on http://haskellbook.com

Seems reasonable, but much of the consternation over GHC dev process has been about the relative illegibility of it, even for working programmers who've hacked on compilers before. It's concerning to see a list of items about a "contribute to GHC" discussion that seemingly includes nothing that addresses this. Can you point me to any discussions among GHC devs on this since the last time it was raised? On Sat, Sep 24, 2016 at 6:41 PM, Joachim Breitner wrote:

Hi,

Am Samstag, den 24.09.2016, 18:36 -0500 schrieb Christopher Allen:

...

...

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

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

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

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

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

Greetings, Joachim

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

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

-- Chris Allen Currently working on http://haskellbook.com

Why are contributions via Github limited to things that don't require review? That won't encourage anyone to get started because they know that as soon as they move on to something substantive, they'll hit the same brick wall. You can't boil a frog by taking it out of the pot of lukewarm water and tossing it into the roiling kettle. Have you looked at how Rust handles contributions to the compiler? https://github.com/rust-lang/rust They don't rely on bare Github, they use bots to automate and add structure in the ways you're trying to wring out of Phabricator. The automation and community they've built here is above and beyond anything I've seen in any other community, it is _outstanding_ and it behooves us to learn what they do and to take it seriously. Rust has five times the contributors GHC does and the depth of contributions do not trail off as quickly. Rust has been around for less time than many popular Haskell libraries! To see more of how Rust developers and users discuss new features and improvements, this forum is illuminating: https://internals.rust-lang.org/ I work with someone that has contributed to GHCJS more than once, but will not go anywhere near GHC. This is almost entirely because of the opaque process. Another: https://github.com/purescript/purescript 94 contributors, only a couple years old, written in Haskell but has many users who came from JS and don't know any Haskell, used mostly for frontend work. Putting aside Github's new code review functionality (which seems fine but isn't anything terribly impressive), there are lots of ways to skin the code review cat without putting new contributors in a typo-fix PR ghetto. On Sat, Sep 24, 2016 at 6:53 PM, Joachim Breitner wrote:

Hi,

Am Samstag, den 24.09.2016, 18:46 -0500 schrieb Christopher Allen:

...

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

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

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

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

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

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

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

Greetings, Joachim

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

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

-- Chris Allen Currently working on http://haskellbook.com

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

My point is that at almost every level, contributing to GHC is a chore. Phabricator/Github is simply a good place to start for opening things up, but it's far from the only thing. http://www.arcadianvisions.com/blog/2016/ghc-contributing.html has the ring of verisimilitude to me and most working Haskellers I know. This bright line between the users of Haskell and the contributors to the primary compiler is not healthy long-term. The consistently dismissive attitude towards these objections is not good either. GHC has a very poor showing compared to other compilers with similar sets of users (FP, typed, or modern) in terms of onboarding new people and you won't take these critiques seriously. You do the bare minimum just so you can say you did something, but not substantive is open for discussion. This fools no-one!

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

Hype draws consumers, not producers! Excellent process, documentation, and community is what turns those consumers into producers! This is so short-sighted and wrong that I don't think there's any point in my saying more. You've made it clear you don't care. On Sat, Sep 24, 2016 at 7:17 PM, Matthew Pickering wrote:

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

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

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

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

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

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

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

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

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

Matt

On Sun, Sep 25, 2016 at 12:36 AM, Christopher Allen wrote:

...

...

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

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

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

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

...

Phyx writes:

...

...

...

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

\o/

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

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

The solution here is to extend Harbormaster coverage, which is on my list anyways. My priorities is roughly,

...

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

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

Cheers,

- Ben

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

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

-- Chris Allen Currently working on http://haskellbook.com

As a side observer, I find Christopher's comments to be spot on. My lack of familiarity with phab has definitely de-railed my in-flight patch, adding implicit parameter and recursive do support to Template Haskell. Certainly my own fault, but also induced by friction that feels unnecessary. On Sat, Sep 24, 2016 at 5:40 PM, Brandon Allbery wrote:

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

...

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

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

-- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

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

Why are you so hostile to Chris? I don’t think that this is an appropriate way to treat somebody who is making a suggestion in good faith. Chris may not have contributed to GHC, but apart from co-authoring the currently most popular Haskell book, he has consistently contributed to helping people who are new to the language (on Slack, IRC, in blog posts, etc). He has suck a ton of time into moving the language forward. Moreover, he knows a thing or two about helping newcomers in an effective manner. And he is right in his critique that it is hard to contribute to GHC. For example, I recently wrote a patch concerning compatibility with macOS Sierra and even posted about it on this list: https://mail.haskell.org/pipermail/ghc-devs/2016-July/012512.html https://mail.haskell.org/pipermail/ghc-devs/2016-July/012512.html It’s a small patch, and I just don’t have the time to jump through all the hoops to get it into the repo. And now before you accuse me of not having contributed to GHC, maybe check the git logs first. In summary, if you don’t want to consider that maybe it is harder to contribute to GHC than it has to be and making it easier maybe would lead to more contributions, that is one thing. However, I do insist that suggestions made in good faith on this list are treated politely and not being brutally shot down. Simon, I imagine you agree with me here. Manuel

Brandon Allbery :

On Sat, Sep 24, 2016 at 8:38 PM, Christopher Allen mailto:cma@bitemyapp.com> 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 allbery.b@gmail.com mailto:allbery.b@gmail.com ballbery@sinenomine.net mailto:ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net http://sinenomine.net/_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

I'd be willing to help with work required to open up GHC development more along multiple lines including: Bots/automation for Github Talking to Rust devs about what works, what doesn't Talking to GHC devs about what works, what doesn't, comparing/contrasting with other processes such as Rust's Papering all this up into a "where we are, where we'd like to go" document Writing documentation and tutorials for getting new developers on board Manually on-boarding new developers I am willing to do this work in addition to my 9-5 work using Haskell, the book(s) which are a full-time job unto themselves, and the open source work I do. I will not do any of this as long as this is the attitude of GHC developers. I can not in good conscience encourage people to contribute to a project controlled and represented with such hostility and dismissiveness. The needs of the community and of new and casual contributors have to be taken seriously. This is not for their sake alone, it's to ease the workload of the maintainers and to mend the worsening culture gap. On Sat, Sep 24, 2016 at 8:19 PM, Brandon Allbery wrote:

On Sat, Sep 24, 2016 at 9:08 PM, Manuel M T Chakravarty wrote:

...

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

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

-- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

-- Chris Allen Currently working on http://haskellbook.com

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

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

Bots/automation for Github

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

Last year I approached some folks in the rust community because I wanted to learn how to contribute to the rust compiler. In my experience, the really special thing they had was an identified pool of contributors who were willing and able to provide mentoring. I got hooked up with a mentor and that made all the difference. I had a real live person I could talk to about the process, the process-meta, and that person had context with me. Pretty much everything else was just details. GHC dev probably has mentors too, but I don't know because I've never thought to check or ask.

Hi,

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

I hope and assume that already now that every possible contributor who has questions like this and asks (e.g. on irc) will get a helpful answer. Is that insufficient? Greetings, Joachim -- Joachim “nomeata” Breitner   mail@joachim-breitner.de • https://www.joachim-breitner.de/   XMPP: nomeata@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F   Debian Developer: nomeata@debian.org

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

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

It is also probably lost that I said there was a phabricator module 'ponder' which gives this kind of functionality so it should be quick and easy to setup. Matt On Sun, Sep 25, 2016 at 9:23 AM, Harendra Kumar wrote:

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

...

Hi,

...

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

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

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

-harendra

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

Hi all, I agree with Elliot that the idea of a mentor is really cool, but may not be feasible at the moment. While the "on-demand" support (irc, reddit) from the community is great, I believe that a potential new contributor should be able to go as far as possible on their own because: - newcomers may be hesitant to ask dumb questions about GHC (I know I was). - newcomers may get turned away as the task will seems more complicated that it is. - the number of people working full-time on GHC is low. For that, there needs to be a single and accessible place, where newcomers can go and learn about ghc internals, the overall process, and what should the do next to contribute. Currently, there is wiki on trac, which is sometimes correct, sometimes outdated, sometimes slightly chaotic, and sometimes difficult to use. In addition to wiki, every member in the community is actively encouraged to try out new features in ghc and blog about their experience, which works perfectly fine for a tightly knit community, but presents an insurmountable barrier of entry for newcomers. I proposed using stack overflow, as they are adding a new feature called [documentation](http://stackoverflow.com/documentation), which allows to maintain a list of examples for a given tag. For instance, there is a stack overflow documentation for [haskell]( http://stackoverflow.com/documentation/haskell/topics). Furthermore, I believe that most potential newcomers will be familiar with using stack overflow. Next week, I will start cleaning up the wiki, as there are some pages and guides for newcomers which are out of date and cause unnecessary headaches for people that are unfamiliar with ghc. I will figure out and fill any missing information regarding checking out the source and I will check if there are any wiki entries that need to be deduplicated. Best wishes, Jakub On Sun, 25 Sep 2016 at 20:47, Elliot Cameron wrote:

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

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

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

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

Elliot Cameron

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

...

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

...

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

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

Matt

On Sun, Sep 25, 2016 at 9:23 AM, Harendra Kumar wrote:

...

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

...

wrote:

...

Hi,

...

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

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

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

mail@joachim-breitner.de> list

...

(one more list!) can give the impression of a lower barrier for sending stupid or operational questions.

-harendra

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

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

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

Jason Dagit writes:

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

...

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

Bots/automation for Github

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

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

GHC dev probably has mentors too, but I don't know because I've never thought to check or ask.

Indeed we do! If you ever have questions just ask me via IRC or email. I'd be very happy to help. Even while I may not know the answer I (or anyone else in #ghc) will likely be able to send you to someone who does. Cheers, - Ben

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

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

Does that include having Mozilla Corp. backing them? What is your suggestion for this? I understand that you think this is an important cause for the dearth of contributors --- I've watched enough would-be contributors bounce off the code base (long before even considering the tooling) and give up to have major doubts, as underlined by Richard's recent message --- but throwing everything out and building a new infrastructure is not something that happens by itself. It needs *people* and it needs *time*. And it's harder (and needs more people and more time) when you have a couple decades' worth of history (which Rust did not). If you have a solution to this problem, I'm sure people would like to hear it. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

It really is difficult to proceed when the problem is not well defined. I also find it insulting that you suggest that I (and other developers) don't care about bringing new users to the project. The nebulous suggestion that GHC developers have ulterior motives is also not becoming of a productive discussion. There's clearly much more to be said but it seems pointless to proceed any further. Matt On Sun, Sep 25, 2016 at 1:38 AM, Christopher Allen wrote:

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

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

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

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

...

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

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

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

On Sat, Sep 24, 2016 at 7:17 PM, Matthew Pickering wrote:

...

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

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

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

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

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

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

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

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

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

Matt

On Sun, Sep 25, 2016 at 12:36 AM, Christopher Allen wrote:

...

...

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

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

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

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

...

Phyx writes:

...

...

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

\o/

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

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

The solution here is to extend Harbormaster coverage, which is on my list anyways. My priorities is roughly,

...

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

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

Cheers,

- Ben

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

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

-- Chris Allen Currently working on http://haskellbook.com

Joachim Breitner writes:

Hi,

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

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

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

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

First of all thank you for the help you've given me so far. Maybe I'm different from others, but my workflow as a newcomer was just reading https://ghc.haskell.org/trac/ghc/wiki/Newcomers. My extremely unsophisticated idea is to just update this wiki page so that it's obvious there are people who are willing to mentor newcomers. It seems as though we already have mentors or people willing to be mentors, but we also have people who did not know this was available. More specifically, I think it would be useful if under the "Finding a Ticket" section, as an alternative to just picking a ticket, we suggest people to ask either through email or on IRC for a starter ticket. Then, hopefully the people who would be willing to mentor this person can suggest tickets they are equipped to deal with themselves. By having newcomers ask for a ticket, we can guarantee that if this person gets a response there would be a mentor available. Also, if someone is too busy to be a mentor, then that person could just choose not to volunteer so that nobody should get overburdened, or at least any more overburdened than they already are. It might seem silly and I am probably just too shy, but as someone new I am always very hesitant to email the entire mailing list for help. On the other hand, I also feel bad for emailing a specific person because I figure they are likely very busy. If I were assigned someone to ask for help, especially someone who volunteered himself or herself, I suspect I would not feel so embarrassed to ask for help. I probably should have asked for help more on IRC but to be honest I have only used IRC once or twice in my life, incidentally also for help on Haskell, so it's not something I really remember. On Mon, Sep 26, 2016 at 12:13 PM, Ben Gamari wrote:

Simon Marlow writes:

...

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

- Adding another input method complicates the workflow, users have to decide which one to use

I think we would want to try to sell the GitHub route as "if you would like to contribute then we would strongly prefer you use Phabricator, but if you must and it's a small patch, we will accept it via GitHub."

...

- Github is not integrated with our other infrastructure, while Phabricator is

True, but I suspect for the small documentation patches that we are currently consider this shouldn't matter so much.

...

- Mutliple sources of contributions makes life harder for maintainers

It does certainly put yet another task on our plates, but I would argue that it's actually easier than accepting patches via Trac, which we already do.

...

Let's make the Phabricator workflow easier.

- Why not put arc in the repo, or provide a script that automatically downloads it and sets it up?

I'm not sure how much of a difference placing arc in the repo will make; the user will still at very least need to install PHP manually.

...

- I also like the idea of auto-push if validate succeeds. Or a button that you can press on the diff that would do the same thing, so you can get code review first.

To be clear, I'm a bit weary of opening up the auto-push feature to new contributors. While regular contributors know what changes can be safely pushed and which require review, we have no guarantee that a new contributor has developed these sensibilities.

...

- +1 to making the manual easier to build. The same goes for Haddocks; it's really hard to make a simple patch to the docs and test it right now.

The users guide should be quite possible to do.

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

...

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

Agreed.

Cheers,

- Ben

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

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

Simon Marlow writes:

...

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

- Adding another input method complicates the workflow, users have to decide which one to use

I think we would want to try to sell the GitHub route as "if you would like to contribute then we would strongly prefer you use Phabricator, but if you must and it's a small patch, we will accept it via GitHub."

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

- Github is not integrated with our other infrastructure, while

...

Phabricator is

True, but I suspect for the small documentation patches that we are currently consider this shouldn't matter so much.

...

- Mutliple sources of contributions makes life harder for maintainers

It does certainly put yet another task on our plates, but I would argue that it's actually easier than accepting patches via Trac, which we already do.

We should stop accepting patches via Trac too :) Cheers Simon

...

- I also like the idea of auto-push if validate succeeds. Or a button that you can press on the diff that would do the same thing, so you can get code review first.

To be clear, I'm a bit weary of opening up the auto-push feature to new contributors. While regular contributors know what changes can be safely pushed and which require review, we have no guarantee that a new contributor has developed these sensibilities.

...

- +1 to making the manual easier to build. The same goes for Haddocks; it's really hard to make a simple patch to the docs and test it right now.

The users guide should be quite possible to do.

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

...

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

Agreed.

Cheers,

- Ben

Simon Marlow writes:

But this is opening the floodgates a crack... how do we know what a "small" patch is? What happens when someone submits a patch that's too large?

I tried to address these questions in the "Create a ghc-simple-patch-propose list?" thread where I said, Ben Gamari writes:

I completely agree that for small (e.g. documentation) patches our current system is quite heavy. For this reason I suggested at ICFP that we simply begin accepting small patches via GitHub pull requests. Frankly, this is less work for me than merging patches from a mailing list and I believe many users feel that GitHub is more accessible than a mailing list.

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

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

Does this help? Simon Marlow writes:

The patches will get larger, we'll have to do code reviews on two different tools, and it will be really hard to go back. I just have a bad feeling about this.

I share your worry that the GitHub patch sizes will "creep". That being said, I think that as long as we can easily move to Phabricator for reviewing larger patches it will be manageable. Moreover, I suspect that once someone has submitted a patch via GitHub, the effort that they have sunk into it will mean that they will be more likely to follow the patch to Phabricator to participate in review (and hopefully revision) if we move it.

...

It does certainly put yet another task on our plates, but I would argue that it's actually easier than accepting patches via Trac, which we already do.

We should stop accepting patches via Trac too :)

Heh, it would certainly make my life easier. That being said, there (thankfully) aren't too many that come in via this channel at this point. Cheers, - Ben

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

Simon Marlow writes:

...

But this is opening the floodgates a crack... how do we know what a "small" patch is? What happens when someone submits a patch that's too large?

I tried to address these questions in the "Create a ghc-simple-patch-propose list?" thread where I said,

Ben Gamari writes:

...

I completely agree that for small (e.g. documentation) patches our current system is quite heavy. For this reason I suggested at ICFP that we simply begin accepting small patches via GitHub pull requests. Frankly, this is less work for me than merging patches from a mailing list and I believe many users feel that GitHub is more accessible than a mailing list.

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

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

Does this help?

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

Simon Marlow writes:

...

The patches will get larger, we'll have to do code reviews on two different tools, and it will be really hard to go back. I just have a bad feeling about this.

I share your worry that the GitHub patch sizes will "creep". That being said, I think that as long as we can easily move to Phabricator for reviewing larger patches it will be manageable.

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

...

...

It does certainly put yet another task on our plates, but I would argue that it's actually easier than accepting patches via Trac, which we already do.

We should stop accepting patches via Trac too :)

Heh, it would certainly make my life easier. That being said, there (thankfully) aren't too many that come in via this channel at this point.

Cheers,

- Ben

On Tue, Sep 27, 2016 at 8:20 AM, Alexander V Vershilov wrote:

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

I think this could make a great deal of sense. This will allow us to use the familiar GitHub interface for creating PRs, but all PRs will be maintained within phabricator. Creating a PR should automatically cause the user to create an account on Phabricator, if possible. I've done a quick search to see if a tool exists for this, and all I found was this abandoned patch in the phabricator project itself. https://secure.phabricator.com/D8775 Unfortunately (or fortunately, hah!), I do not know PHP. However, if phabricator has a RESTful API it seems imminently feasible to implement this as a bot written in Haskell.

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

-- Alexander

On 24 September 2016 at 04:44, Simon Peyton Jones via ghc-devs wrote:

...

Friends

Here are the notes I took from session 2 of the Haskell Implementors Meeting. The bolding is my choice of emphasis.

Simon

· Doc bugs. Two kinds

o Typos. Friction stops me

o Explanations needed e.g. read/show

· Lightweight pushes

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

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

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

· Docker images. We should have one.

· Remove old documentation!

· Cross compilation is difficult.

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

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

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