Re: Phabricator for patches and code review
Could not have agreed more with Manuel. I would also like to point out that one of the missions of the arcanist tool is to support all version control systems. That have made sense for FaceBook Inc, who went from Subversion to Git to Mercurial. GHC team only use git now. I think the consequence is that the arcanist command line tool becomes quite weak*, for example I were not able to push a given gitrevision, you have to go through `arc diff` which only pushes the commit that HEAD is at. For sure github is the lead thing most everyone is using and already know how to use. As for side-by-side diffs on github, there is a browser extension for it. But yes, the Phabricator has a better review tool. :) Cheers, Arash * Based on my experience with it from my summer internship at FaceBook 2013. On 2014-06-07 07:21, Manuel M T Chakravarty wrote: So, why not put everything on GutHub and use pull requests and so on? SimonM writes that Phabricator is better than GitHub. I’m happy to believe that, but he also writes that using it requires installing local software and quite a bit of work. Moreover, I like to add that lots of people already know how to use GitHub and probably few know Phabricator. So, we are talking about having a somewhat better tool in return for three very significant disadvantages: (1) local installation, (2) work to set up and maintain Phabricator, and (3) effort by many people to learn to use it. We also have a constant lack of sufficient men power. So, why spend effort on building our own infrastructure, which will only increase the hurdle for contributors (as they have to deal with an unknown system)? Let’s outsource the effort to GitHub. Manuel Simon Peyton Jones simo...@microsoft.com: At the moment GHC's main sources aren't on github, which means that that (in my highly imperfect understanding) people can't submit pull requests or use their code review mechanisms. Moreover, most people don't have commit rights on the main GHC server, so if someone wants to offer a patch they can really only do so in textual form attached to Trac. People with commit rights can make a branch, but there's a danger that over a decade we'll accumulate zillions of dead branches which people forgot to delete. I think on github the branch is in a different repo, belonging to the patch author. So we really don't have a good work flow for creating, reviewing, modifying, and finally apply patches. I am no expert on these matters. If Phabricator would help with that I'm all for it. But perhaps there are other alternatives? Or is Phab the lead thing. Will it stay around? Also before going too far I'd really like someone to document the workflow carefully, and make sure it works from Windows equally well. I'm not too stressed out about losing the review trail of a patch. Much of it will be commenting on stuff that no longer appears in the final patch. Anything that's important should appear in a Note in the source code; even the commit messages are invisible until you really start digging. Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Austin | Seipp | Sent: 06 June 2014 05:06 | To: ghc-devs@haskell.org | Subject: RFC: Phabricator for patches and code review | | Hello all, | | Recently, while doing server maintenance, several of the administrators | for Haskell.org set up an instance of Phabricator[1], located at | https://phabricator.haskell.org | | For those who aren't aware, Phabricator (or Phab) is a suite of tools | for software development. Think of it like a polished, semi-private | GitHub with a lot of applications and tools for all kinds of needs. | We've been using it to do issue tracking for Haskell.org maintenance and | like it a lot so far. | | One very nice aspect of Phabricator though is it has a very nice code | review tool, called 'Differential', that is very useful. For people who | have used a tool like Review Board, it's similar. Furthermore, it has a | very convenient userland tool called 'Arcanist' which makes it easy for | newcomers to post a review and get it merged when it's ready all from | the command line. | | I'd like to see if people are interested in using Phab _strictly_ for | code review of GHC patches. It is a dedicated tool specifically for | this, and I think it works much better than Trac or inline GitHub | comments. | | Also, Phab can also support post-commit reviews. So if I touch something | in the runtime system and just push, perhaps Simon or Edward would like | to look, and they can be alerted right when I do this, and then yell if | I did something stupid. | | Before I go much further, I'd like to ask: is there *any* interest in | this? Or are people satisifed with Trac? The primary motivations are | roughly, in no particular order: | | 1) Code review is good for everyone, a good way for people to learn the | code and ask questions, and useful to give feedback to
Re: Phabricator for patches and code review
On 06/07/2014 07:21 AM, Manuel M T Chakravarty wrote: So, why not put everything on GutHub and use pull requests and so on? SimonM writes that Phabricator is better than GitHub. I’m happy to believe that, but he also writes that using it requires installing local software and quite a bit of work. Moreover, I like to add that lots of people already know how to use GitHub and probably few know Phabricator. So, we are talking about having a somewhat better tool in return for three very significant disadvantages: (1) local installation, (2) work to set up and maintain Phabricator, and (3) effort by many people to learn to use it. We also have a constant lack of sufficient men power. So, why spend effort on building our own infrastructure, which will only increase the hurdle for contributors (as they have to deal with an unknown system)? Let’s outsource the effort to GitHub. Manuel While I'm usually in favour of using GitHub for something due to the sheer amount of exposure to people with existing accounts, I have to say that there are few major deficiencies with it for this particular task: issue tracking is crap, you can do very little in ways of customisation, the TOS is pretty scary, labels are not sufficient enough for anything serious, it's very easy to miss comments on specific lines…. It's really not suited for medium/large scale issue tracking and code review. I do agree with you on the 3 disadvantages of using something like Phabricator (and I add an extra one that now a browser so for example you can't use it on X-less box although I'm not sure what the locally installed software does) but if people reading the patches (Austin, Herbert, anyone concerned at the moment) find it easier to do their job AND it becomes easier to ask for feedback then I think we should give it a go. As it stands, I'd rather use e-mail + few policies for code review c rather than GitHub which is really not suited for this task. Big downside of e-mail/Trac for this is it's hard to give iterative feedback on changing parts of patches. Simon Peyton Jones simo...@microsoft.com: At the moment GHC's main sources aren't on github, which means that that (in my highly imperfect understanding) people can't submit pull requests or use their code review mechanisms. Moreover, most people don't have commit rights on the main GHC server, so if someone wants to offer a patch they can really only do so in textual form attached to Trac. People with commit rights can make a branch, but there's a danger that over a decade we'll accumulate zillions of dead branches which people forgot to delete. I think on github the branch is in a different repo, belonging to the patch author. So we really don't have a good work flow for creating, reviewing, modifying, and finally apply patches. I am no expert on these matters. If Phabricator would help with that I'm all for it. But perhaps there are other alternatives? Or is Phab the lead thing. Will it stay around? Also before going too far I'd really like someone to document the workflow carefully, and make sure it works from Windows equally well. I'm not too stressed out about losing the review trail of a patch. Much of it will be commenting on stuff that no longer appears in the final patch. Anything that's important should appear in a Note in the source code; even the commit messages are invisible until you really start digging. Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Austin | Seipp | Sent: 06 June 2014 05:06 | To: ghc-devs@haskell.org | Subject: RFC: Phabricator for patches and code review | | Hello all, | | Recently, while doing server maintenance, several of the administrators | for Haskell.org set up an instance of Phabricator[1], located at | https://phabricator.haskell.org | | For those who aren't aware, Phabricator (or Phab) is a suite of tools | for software development. Think of it like a polished, semi-private | GitHub with a lot of applications and tools for all kinds of needs. | We've been using it to do issue tracking for Haskell.org maintenance and | like it a lot so far. | | One very nice aspect of Phabricator though is it has a very nice code | review tool, called 'Differential', that is very useful. For people who | have used a tool like Review Board, it's similar. Furthermore, it has a | very convenient userland tool called 'Arcanist' which makes it easy for | newcomers to post a review and get it merged when it's ready all from | the command line. | | I'd like to see if people are interested in using Phab _strictly_ for | code review of GHC patches. It is a dedicated tool specifically for | this, and I think it works much better than Trac or inline GitHub | comments. | | Also, Phab can also support post-commit reviews. So if I touch something | in the runtime system and just push, perhaps Simon or Edward
Re: Phabricator for patches and code review
This always gets brought up, but I (still) think there are several reasons to prefer our own infrastructure over GitHub: - Phab is far more flexible, especially for review. GitHub doesn't even have side-by-side diffs (a massive improvement), much less the suite of tools that make code review easy. I cannot set emails to notify me when someone touches something I am the owner of, for example, it's just blind emails all the time. This applies to incoming patches (pre-commit review), and changes merged to the tree (post-commit review). And both of these workflows are useful ones for GHC I think. - I also now think it is *easier* to submit changes for review with Phabricator having done it, because there is a simple command line utility to do so. This utility can easily be integrated into the GHC tree. It is also easier for me to manage patches, or for anyone to merge patches! It's just one more command. And the reality is that most commits need to be validated before we commit them. This has been the standard for a long time - GitHub's automated workflows don't accommodate this. I would rarely, if ever, hit the merge button on GitHub for GHC for example. You must run the tests for foreign patches you are incorporating - always. - I don't think maintenance is an issue. We've been using it for Haskell.org ticket tracking since we needed a replacement for some of our old infrastructure (including private support tickets which GitHub does not support), since we're consolidating it all. The admin team has about 3 people working on it (including me), and we've been doing upgrades, migrating things, automating them, and generally making the servers more redundant and simpler. - I think code review, in general, massively increases the 'shared knowledge' pool for developers, and a dedicated tool really, really helps. I can only point to my experience introducing dedicated tools multiple times in my career in the past as examples. Most people besides me don't really review patches unless I ask them to, and a good tool of pending things that can notify you if you might be interested is really useful. As for GitHub and Trac in general: - GitHub lacks several things we already use. For example, there is no way to add commit hooks to repositories that ban commits containing whitespace, trailing spaces, and other 'lint' errors. git.haskell.org automatically enforces this to help keep new code tab-free. GitHub has no alternative to this. - We also use this facility to keep submodules sane: as of today, git.haskell.org will not let you commit a 'dangling submodule reference' to ghc.git. You must push the corresponding submodule code first, so the top-level repository never breaks. This is also not possible with GitHub and has been a historical error source for developers. - Speaking of builds, any kind of integration with a CI system, at some level, is going to require custom infrastructure on our side, GitHub or not, so there's no clear advantage here. Travis-CI is simply not going to be long-term acceptable for GHC - we are within 5m or so of the build limit, and it only builds GHC with some conservative settings. Also Travis-CI does not allow custom infrastructure, like ARM buildbots, or multiple differently-versioned OS X buildbots. Gabor's nightly servers for example allow all of this. Joachim's builds are very useful though, but we need more. - Speaking of that, we need to maintain our own server so that Git pushes can interface with Trac, and the mailing notifier. - And then you might ask, well we could just migrate it all to GitHub. That's a _huge_ amount of work. GHC is probably one of the largest Trac installations around at nearly 10,000 tickets, a gigantic wiki, and tons of metadata and a *lot* of users. Preserving the necessary metadata, rewriting intra-wiki links, references, and preserving everything is just going to be a ton of work. GitHub doesn't even have an 'import' facility for example, just the raw API, so this would involve a lot of local processing to 'fix' everything. This includes moving labels, etc. I strictly shot down that idea, because it's time I don't think anyone wants to dedicate to it. Dropping all the data is out of the question. Trac is well understood at least and has many valuable aspects, and a migration should be considered a very, very serious matter after a lot more discussion. Phabricator would only be used for GHC code review. On Sat, Jun 7, 2014 at 12:21 AM, Manuel M T Chakravarty c...@cse.unsw.edu.au wrote: So, why not put everything on GutHub and use pull requests and so on? SimonM writes that Phabricator is better than GitHub. I’m happy to believe that, but he also writes that using it requires installing local software and quite a bit of work. Moreover, I like to add that lots of people already know how to use GitHub and probably few know Phabricator. So, we are talking about having a somewhat better tool in return for three very
Re: Offering GHC builder build slaves
2014-06-07 0:17 GMT+02:00 Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk: I notice that the builds with failing test results are still marked as successful. Would it not be useful to indicate that there are failing tests somehow? The result is based on the value that the invoked command returns. That is, for the testing phase, the make test BINDIST=YES command returned ExitSuccess, that is why it is marked green. It'd be a shame to have various test results from multiple machines but not use them. I see what you mean. But I would also feel strange to mark the test results failed if only a few of them fail. Note that the testsuite summaries are forwarded to the ghc-builds mailing list so they are published and archived. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Offering GHC builder build slaves
Hi, Am Samstag, den 07.06.2014, 12:21 +0200 schrieb Páli Gábor János: 2014-06-07 0:17 GMT+02:00 Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk: It'd be a shame to have various test results from multiple machines but not use them. I see what you mean. But I would also feel strange to mark the test results failed if only a few of them fail. Note that the testsuite summaries are forwarded to the ghc-builds mailing list so they are published and archived. ideally, these would be collected in a meaningful way, so that one can see „Commit 123 changed the number of failing tests from 2 to 3“ or „Test T1234 fails since 1.1.2014“ or so. Ideally together with performance numbers („This commit improved nofib by x%“) and nice graphs. It must be possible to collect and present such results that without reinventing the wheel, I just haven’t seen such a tool yet. (And I know that „we should have X“ mails are not very useful...) Greetings from Zürich, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-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://www.haskell.org/mailman/listinfo/ghc-devs
Re: [GHC] #8226: Remove the old style -- # Haddock comments.
Thanks Fuuzetsu,
Tomorrow I'll still be at the ZuriHac, so hopefully I'll able to adjust the
patch :)
I'll poke you if you'll be around
Thanks!
Alfredo Di Napoli
On 07/giu/2014, at 07:23, GHC ghc-devs@haskell.org wrote:
#8226: Remove the old style -- # Haddock comments.
-+
Reporter: Fuuzetsu |Owner:
Type: task | Status: patch
Priority: normal|Milestone: 7.10.1
Component: Compiler | Version: 7.7
Resolution:| Keywords:
Operating System: Unknown/Multiple | Architecture: Unknown/Multiple
Type of failure: None/Unknown | Difficulty: Unknown
Test Case:| Blocked By:
Blocking:| Related Tickets:
-+
Comment (by Fuuzetsu):
Sorry I fell behind a bit on reading GHC tickets.
Yes adinapoli, those should also be removed, we do not use --# for
anything and it served the same purpose as {-# as far as I know.
Also the data type used to store that type of comment should be removed:
https://github.com/ghc/ghc/blob/master/compiler/parser/Lexer.x#L625
FTR the Haddock ticket is now tracked at
https://github.com/haskell/haddock/issues/171
Thanks for looking into this, feel free to poke me on IRC/e-mail if you
need more immediate review.
--
Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8226#comment:5
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC/cabal release procedures, and Stackage
Hi Michael, Am Samstag, den 07.06.2014, 21:06 +0300 schrieb Michael Snoyman: If there was a daily snapshot build, I would be happy to set up some kind of regular process to download that snapshot and do a Stackage run on it. I'm currently blocked on this kind of activity, since I can't get a successful GHC 7.8 build due to my system using the Gold linker. That would be great, both for GHC and for people who want to have their packages work on GHC HEAD without manually monitoring it. There is http://deb.haskell.org/ which should produce daily debian packages for Debian wheezy. I guess if you are building on that platform, such packages are easiest to use (as you need no particular tooling to update and install). http://deb.haskell.org/dailies/latest/ is currently lagging due to temporary full disk, but I hope that by tomorrow, we have a new build. There used to be daily snapshot builds at http://darcs.haskell.org/ghcBuilder/uploads/ but that is defuct (Can someone remove the link from http://www.haskell.org/ghc/download). I wonder if the “new” builder infrastructure at http://haskell.inf.elte.hu/builders/ assembles the snapshots somewhere, then you can use them. Or you can build GHC yourself as part of the stackage run. Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-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://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC/cabal release procedures, and Stackage
On 06/07/2014 11:57 PM, Joachim Breitner wrote: Hi Michael, Am Samstag, den 07.06.2014, 21:06 +0300 schrieb Michael Snoyman: If there was a daily snapshot build, I would be happy to set up some kind of regular process to download that snapshot and do a Stackage run on it. I'm currently blocked on this kind of activity, since I can't get a successful GHC 7.8 build due to my system using the Gold linker. That would be great, both for GHC and for people who want to have their packages work on GHC HEAD without manually monitoring it. There is http://deb.haskell.org/ which should produce daily debian packages for Debian wheezy. I guess if you are building on that platform, such packages are easiest to use (as you need no particular tooling to update and install). http://deb.haskell.org/dailies/latest/ is currently lagging due to temporary full disk, but I hope that by tomorrow, we have a new build. There used to be daily snapshot builds at http://darcs.haskell.org/ghcBuilder/uploads/ but that is defuct (Can someone remove the link from http://www.haskell.org/ghc/download). I wonder if the “new” builder infrastructure at http://haskell.inf.elte.hu/builders/ assembles the snapshots somewhere, then you can use them. Some builders such as upload snapshots but I don't know how it's decided which. See [1] for example of such build. I think Pali makes the call. Or you can build GHC yourself as part of the stackage run. Greetings, Joachim ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs [1]: http://haskell.inf.elte.hu/builders/freebsd-amd64-head/282.html -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
