
On Tue, Sep 27, 2016 at 8:20 AM, Alexander V Vershilov
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