I found a list of StackOverflow clones. (I don't know how difficult it
is to get an official StackExchange site, or if we would even want that)
http://meta.stackexchange.com/questions/2267/stack-exchange-clones
On Fri, Sep 23, 2016, at 18:44, Simon Peyton Jones via ghc-devs wrote:
> Friends
>
>
Hi,
I’ll add some notes to extend the discussion to the mailing list.
Am Samstag, den 24.09.2016, 01:44 + schrieb Simon Peyton Jones via
ghc-devs:
>
> · Make user manual into its own repo, to make it easier to
> take pull requests. But that makes it harder when making
> synchronised
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-
>>
>> ·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
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
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
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
>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 t
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 n
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 add
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
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 d
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
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
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 contr
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 H
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 wo
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
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 S
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
peopl
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 s
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 lo
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
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
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
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
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 th
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
mentor
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 b
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
If we loop this discussion back to the original post. There is a
suggestion in there which seems to be what you are looking for.
> Have a GHC StackOverflow on haskell.org (Jacob Zalewski jakz...@gmail.com
> offers to do this! – thank you). It has a useful new Documentation feature.
> Eg th
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 i
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
I would rather we *didn't* accept contributions via github, even for small
patches, and instead put more effort into streamlining the Phabricator
workflow.
- Adding another input method complicates the workflow, users have to
decide which one to use
- Github is not integrated with our oth
Thank you for this comment Anthony.
I thought about it over the last day and think you have it spot on.
This is the key sentence:
> The truth is that it what I complained about is *not a problem*
> for GHC devs in so far as they are happy doing GHC development!
It seems that the point that you ar
Christopher Allen writes:
>>I think the we'd want to restrict this to Diffs submitted by
>>contributors who already possess commit bits and specifically include
>>a "no-review" tag in the summary.
>
> Is this intended to address the issues new contributors have in
> contributing to GHC? This look
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
>>
>
> La
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 th
>
> 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
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 complic
On Mon, Sep 26, 2016 at 12:40 PM, Simon Marlow wrote:
> On 26 September 2016 at 20:13, Ben Gamari wrote:
>>
>> Simon Marlow writes:
>>
>> > I would rather we *didn't* accept contributions via github, even for
>> > small
>> > patches, and instead put more effort into streamlining the Phabricator
Richard Fung writes:
>> Indeed we do! If you ever have questions just ask me via IRC or email.
>> I'd be very happy to help.
>
> First of all thank you for the help you've given me so far.
>
Of course! I'm happy that I could help.
Moreover, thanks for writing this. This sort of feedback is worth
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 write
>
> That is a great point; it's easy for me to forget how I felt when I was
> a beginner. I've added a brief paragraph to the Newcomers page,
> If you have any questions along the way don't hesitate to reach out
> to the community. There are people on the mailing lists and IRC who
> wil
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-s
Friends
Wow! I didn't expect my scrappy notes to generate so much traffic!
Some quick thoughts:
* My notes were typed in real-time, during an open 70-person
discussion during the Haskell Implementors Workshop. Air-time was
limited, and I just wanted to capture suggestions that people made.
I think I'm a bit late for the party.
I'm speaking with the newcomer hat on, as basically I have
contributed only few trivial patches. So not sure if my experience
matter.
Originally I was submitting patches using Trac, but then was kindly
asked (IIRC by Simon Marlow) to use Phab instead. Surpris
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 welco
In writing the following huge wall of text, I had and idea that I think
many folks would find palatable:
What if simple small patches (such as hypothetical drive by doc patches )
had a mailing list where folks could email the simple / small patches as
email attachments plus a body text that summar
I like this solution a lot, Carter!
Mailing patches directly to the ghc-devs list could be intimidating
for newcomers. Having a list specific to patch review could make the
process less intimidating. From a perspective of overall contribution
intimidation, these 2 pages make it seem like a ton o
I dislike this approach, having to already deal with a project that does
patches via mailing lists it is very hard to follow conversations. As soon
as multiple people get involved things fall apart.
I have multiple mailing rules and other things just so I can keep track of
comments. And then volum
> "CS" == Carter Schonwald writes:
CS> What if simple small patches (such as hypothetical drive by doc patches )
CS> had a mailing list where folks could email the simple / small patches as
CS> email attachments plus a body text that summarizes the patch, what it
CS> does, and why it's simple
Carter Schonwald writes:
> In writing the following huge wall of text, I had and idea that I think
> many folks would find palatable:
>
> What if simple small patches (such as hypothetical drive by doc patches )
> had a mailing list where folks could email the simple / small patches as
> email at
Phyx writes:
> I dislike this approach, having to already deal with a project that does
> patches via mailing lists it is very hard to follow conversations. As soon
> as multiple people get involved things fall apart.
>
I think accepting pull requests via GitHub can be done with minimal
involveme
This sounds like an ideal solution, Ben! As has been discussed many
times before, GitHub has many users familiar with its interface. By
allowing GitHub PRs, the initial contribution
I think it would be acceptable for larger GitHub PRs to have some
automated boilerplate response. Ideally this wo
Argh, sent too soon. The first paragraph, revised:
This sounds like an ideal solution, Ben! As has been discussed many
times before, GitHub has many users familiar with its interface. By
allowing GitHub PRs, the initial contribution barrier will be lowered. If
there is an easy and straightforwa
Sounds like a great idea to me and might alleviate SimonM’s concerns about
fragmentation of dev attention.
Manuel
> Michael Sloan :
>
> Argh, sent too soon. The first paragraph, revised:
>
> This sounds like an ideal solution, Ben! As has been discussed many
> times before, GitHub has many u
To sum up, this proposes the following:
1. Allow PRs on GitHub.
2. Michael Sloan to write a new utility, ghc-hub, which automates tasks
interfacing between GitHub and Phab. This utility would be used only by GHC HQ
and not by contributors.
3. Small GitHub PRs can be merged directly, by ghc-hub
You're welcome Richard! I look forward to helping make it happen. In
the other thread, Alexander Vershilov mentioned that we might instead
consider the following more straightforward workflow:
0) Have a bot that watches github for PRs.
1) Submit whatever you want to github as a PR.
2) It will be
So you're suggesting that GitHub would function as a sort of alternate
front-end to Phab. While I've grown to enjoy Phab quite a bit, I still strongly
dislike arc, which tries to be too clever for my tastes. Provided the
integration works smoothly, I quite like this idea.
Richard
> On Sep 27,
Hi,
I think it would be great if this was proposed formally. If we could
integrate this with the improved ghc development proposal[1], this
would be great! Or turn it into a separate proposal and remove the
similar parts from the one mentioned.
However, on the topic, I’d like to share a few thoug
On Tue, Sep 27, 2016 at 6:49 PM, Moritz Angermann wrote:
> Hi,
>
> I think it would be great if this was proposed formally. If we could
> integrate this with the improved ghc development proposal[1], this
> would be great! Or turn it into a separate proposal and remove the
> similar parts from the
Exactly! So we will be using Phabricator for the review process, but
with the github PRs you can use plain git. This means that new
contributors will only need to learn about phabricator, and arc will
be non-mandatory though probably recommended.
Glad you like the idea :)
-Michael
On Tue, Sep
Well, let's be careful here. I like the idea, but it's not a complete
solution for people who don't want to use arc, because you can't revise a
patch after submission in response to reviews, you would have to open a new
PR.
Perhaps you could build something that would allow revisions to PRs too..
Simon Marlow writes:
> Well, let's be careful here. I like the idea, but it's not a complete
> solution for people who don't want to use arc, because you can't revise a
> patch after submission in response to reviews, you would have to open a new
> PR.
>
I have considered building something like
On Wed, Sep 28, 2016 at 9:06 AM, Ben Gamari wrote:
> That being said, I ultimately decided it would be easier to just
> continue carrying out this workflow by hand considering I don't post
> large series of patches *that* often. I'm also a bit more eager to
> squash now than I used to be, in part
I don't think Phabricator tries to be or emulate fit in any way; I think this
is a misconception. The way I see it, phabricator is just a glorified
diff-dump, which is supposed to work with any VCS in principle.
All that arc essentially does is, compute the diff from an offset (e.g. master)
to
Moritz Angermann writes:
> I don't think Phabricator tries to be or emulate fit in any way; I
> think this is a misconception. The way I see it, phabricator is just a
> glorified diff-dump, which is supposed to work with any VCS in
> principle.
>
> All that arc essentially does is, compute the di
>> Hence you can go wild on your local branches (use what ever
>> development model suites your needs) and get one final squashed commit
>> with an extensive summary.
>>
> Sure, but this leads to generally unreviewable patches IMHO. In order to
> stay sane I generally split up my work into a set
On Wed, Sep 28, 2016, at 18:37, Ben Gamari wrote:
> Moritz Angermann writes:
>
> > All that arc essentially does is, compute the diff from an offset
> > (e.g. master) to the current HEAD and upload that to a new or existing
> > (--update) differential. It also adds some meta information about the
Hi,
You can alter the content of a GitHub PR after its initial creation. The
semantics of a PR is "please merge my branch named B into your repo" where
the branch B is a mutable pointer to a commit.
A workflow I've used a few times is to craft a nice sequence of commits for
review and, once accep
On Wednesday, September 28, 2016, Eric Seidel wrote:
> On Wed, Sep 28, 2016, at 18:37, Ben Gamari wrote:
> > Moritz Angermann > writes:
> >
> > > All that arc essentially does is, compute the diff from an offset
> > > (e.g. master) to the current HEAD and upload that to a new or existing
> > > (-
>Instead perhaps GitHub's new review system may be the way forward for GHC. It
>allows you to easily use git in the way it's meant to be used.
Many problems are caused by letting your inner tinkerer/genius tailor
dictate how things should be dealt with. Better to cut the gordian
knot. I think Mic
I have tried to gather the ideas from this thread into a formal proposal:
https://github.com/ghc-proposals/ghc-proposals/pull/11
Please feel free to make suggestions to improve this, especially if I've
captured anyone's contributions incorrectly.
-=-=-=-=-=-=-=-=-=-=-
Richard A. Eisenberg
Asst.
Hi Richard!
thanks for creating the pull request with a full proposal. You beat me to
it - tried writing up much the same before stopping for dinner, essentially
capturing just one of the points in Moritz's earlier (large) proposal.
Moritz, I would encourage you like Richard did earlier to split t
Thanks for the useful data point Mathieu. I think it should also be
noted that GHC contributions spiked after switching to phabricator so
it could just be the effect of moving to *some* code review tool.
Could you perhaps summarise the salient points in the LLVM thread? It
is very long with lots of
Matthew Pickering writes:
> Thanks for the useful data point Mathieu. I think it should also be
> noted that GHC contributions spiked after switching to phabricator so
> it could just be the effect of moving to *some* code review tool.
> Could you perhaps summarise the salient points in the LLVM
A nice trick for dealing with stacked diffs in Phabricator is to use "git
rebase -i" to modify diffs in the middle of the stack. You can also insert
"x arc diff" between lines to automatically update later diffs on
Phabricator after a rebase lower down the stack.
You only need a single branch for
On Sat, Oct 1, 2016 at 4:47 PM, Simon Marlow wrote:
> A nice trick for dealing with stacked diffs in Phabricator is to use "git
> rebase -i" to modify diffs in the middle of the stack. You can also insert
> "x arc diff" between lines to automatically update later diffs on
> Phabricator after a r
I added a description of the workflow for multiple dependent diffs here:
https://ghc.haskell.org/trac/ghc/wiki/Phabricator#Workingwithmultipledependentdiffs
Please let me know if anything doesn't make sense. Note that I never let
arc squash my commits, keeping commits 1:1 with diffs makes things
80 matches
Mail list logo
