On Tue, Sep 27, 2016 at 8:20 AM, Alexander V Vershilov <[email protected]> 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 > <[email protected]> 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 >> [email protected] 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 >> [email protected] >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > > > > -- > Alexander > _______________________________________________ > ghc-devs mailing list > [email protected] > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
