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

[Harendra Kumar]

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

-harendra

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

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

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

[Jason Dagit]

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

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

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

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

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

[Brandon Allbery]

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

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

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

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

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

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

[Michael Sloan]

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

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

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

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

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

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

[Richard Fung]

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

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

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

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

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

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

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

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

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

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

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

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

[Christopher Allen]

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

Bots/automation for Github

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

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

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

Writing documentation and tutorials for getting new developers on board

Manually on-boarding new developers

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

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


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



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

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

[Brandon Allbery]

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

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


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

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

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

[Brandon Allbery]

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

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


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

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

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

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

[Manuel M T Chakravarty]

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

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

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

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

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


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

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

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

Simon, I imagine you agree with me here.

Manuel

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

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

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

[Michael Sloan]

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

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

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

[Matthew Pickering]

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

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

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

Matt



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

Re: Adding ConApp to Core

[Manuel M T Chakravarty]

I like this. Having the DataCon only in IdDetails always felt a bit off.

Manuel

> Simon Peyton Jones via ghc-devs :
> 
> Andres, Richard, Stephanie
>  
> The more I think about our idea of introducing ConApp the more I like it.  I 
> wrote it up in a ticket
>  
> https://ghc.haskell.org/trac/ghc/ticket/12618 
> 
>  
> Simon
>  
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org 
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs 
> 
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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

[Brandon Allbery]

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

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

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

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

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

[Christopher Allen]

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

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

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

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

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

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

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

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

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

[Matthew Pickering]

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

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

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

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

And some comments inline:

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

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

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

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

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

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

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

[Brandon Allbery]

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

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

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

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

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

[Matthew Pickering]

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

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

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

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

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

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

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

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

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

Matt

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

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

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

[Christopher Allen]

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

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

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

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

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

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

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

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

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

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

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


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



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

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

[Joachim Breitner]

Hi,

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

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

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

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

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

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

Greetings,
Joachim



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

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

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

[Christopher Allen]

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

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

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



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

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

[Joachim Breitner]

Hi,

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

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

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

Greetings,
Joachim


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

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

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

[Christopher Allen]

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

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

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

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

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



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

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

[Matthew Pickering]

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

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

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

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

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

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

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

>
> ·Lightweight pushes

What does this mean?

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

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

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

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

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

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



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

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

[Ben Gamari]

Phyx  writes:

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

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

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

Cheers,

- Ben


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

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

[Ben Gamari]

Joachim Breitner  writes:

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

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

Cheers,

- Ben


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

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

[Phyx]

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

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

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

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

Adding ConApp to Core

[Simon Peyton Jones via ghc-devs]

Andres, Richard, Stephanie

The more I think about our idea of introducing ConApp the more I like it.  I 
wrote it up in a ticket

https://ghc.haskell.org/trac/ghc/ticket/12618

Simon

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

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

[Eric Seidel]

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

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

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

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

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