similar to: Outdated Phabricator version on reviews.llvm.org breaks Google authentication since today

cc Paul / MyDeveloperDay De : llvm-dev <llvm-dev-bounces at lists.llvm.org> De la part de David Blaikie via llvm-dev Envoyé : April 8, 2020 10:21 PM À : Raphael “Teemperor” Isemann <teemperor at gmail.com>; Manuel Klimek <klimek at google.com> Cc : llvm-dev <llvm-dev at lists.llvm.org> Objet : Re: [llvm-dev] Outdated Phabricator version on reviews.llvm.org breaks Google

Hi folks, phabricator maintenance is a topic that has been lying dormant for a while now. That subsequently creates a non-optimal user experience. For me personally, given that github provides a secure PR infrastructure, the additional effort required to keep Phab going is not an investment I'm personally willing to make. I understand that there are unique selling points for Phab in its UI

Just my 2 cents here: we are working on enabling this as a part of bugzilla migration as PRs and issues are very tied inside GitHub. Stay tuned for updates! On Fri, Jun 19, 2020 at 3:45 PM Manuel Klimek via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > -Chris' outdated email, +Chris' correct email :) > > On Fri, Jun 19, 2020 at 2:01 PM Manuel Klimek <klimek at

On Fri, Jun 19, 2020 at 9:56 AM Hubert Tong via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Fri, Jun 19, 2020 at 12:32 PM Anton Korobeynikov via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Just my 2 cents here: we are working on enabling this as a part of >> bugzilla migration as PRs and issues are very tied inside GitHub. Stay >> tuned for

On Fri, 19 Jun 2020, 18:55 Hubert Tong, <hubert.reinterpretcast at gmail.com> wrote: > On Fri, Jun 19, 2020 at 12:32 PM Anton Korobeynikov via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Just my 2 cents here: we are working on enabling this as a part of >> bugzilla migration as PRs and issues are very tied inside GitHub. Stay >> tuned for updates!

On Fri, Jun 19, 2020 at 1:15 PM Keith Smiley <keithbsmiley at gmail.com> wrote: > FWIW GitHub's code review tools have improved significantly in the past > few years. At this point with reviews and manual control over resolving / > unresolving comments I think many previous complaints I've seen about > GitHub vs Phabricator have been alleviated. > To be clear: this

On Mon, Jun 22, 2020 at 2:33 AM Manuel Klimek <klimek at google.com> wrote: > On Fri, Jun 19, 2020 at 10:04 PM Mehdi AMINI via cfe-dev < > cfe-dev at lists.llvm.org> wrote: > >> >> >> On Fri, Jun 19, 2020 at 9:56 AM Hubert Tong via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> On Fri, Jun 19, 2020 at 12:32 PM Anton

On Fri, Jun 19, 2020 at 4:23 PM Zachary Turner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I use GH daily at my current employer and i can tell you that the issues with rebasing are very real. Unless you only use merge commits you are going to have a very bad time Would it be practical to use merge commits during review (never rebasing) & then rebasing/squashing to

There’s also some feature regressions in GH vs Phab. You *must* initiate a review via a pull request, and pull request by definition compares your working copy against master. This is not very compatible with LLVMs approach to incremental development. For example, if you ask someone to break a large patch into 5 smaller patches, with Phab this is very easy because you can upload the diff

On Mon, Jun 22, 2020 at 9:25 PM David Blaikie <dblaikie at gmail.com> wrote: > On Mon, Jun 22, 2020 at 8:15 PM Mehdi AMINI via cfe-dev > <cfe-dev at lists.llvm.org> wrote: > > > > > > > > On Mon, Jun 22, 2020 at 2:33 AM Manuel Klimek <klimek at google.com> wrote: > >> > >> On Fri, Jun 19, 2020 at 10:04 PM Mehdi AMINI via cfe-dev

I understand that keeping this within one company is easiest from an organization perspective, so if Fangrui and Mehdi (and other Googlers) are able to take this on, that’s great. If not, I can raise this internally at Facebook. An estimate of the total costs incurred would be helpful for that, e.g. you mentioned Sendgrid being a couple of hundred dollars a month. Thanks, Shoaib From: llvm-dev

On Sat, Jun 20, 2020 at 1:45 AM Zachary Turner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > There’s also some feature regressions in GH vs Phab. > > You *must* initiate a review via a pull request, and pull request by > definition compares your working copy against master. > > This is not very compatible with LLVMs approach to incremental > development. For

How much ongoing work do you estimate Phabracitor requires? There’s the times the server falls over (e.g. database exceptions) and needs to be revived, there’s updates to Phabricator itself, there’s keeping the server updated, and probably a bunch of other work I’m not thinking of. About how much of a time commitment would keeping Phabricator going be, in your estimation? From: llvm-dev

On 6/22/20 2:34 AM, Manuel Klimek via llvm-dev wrote: > On Sat, Jun 20, 2020 at 1:45 AM Zachary Turner via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > There’s also some feature regressions in GH vs Phab. > > You *must* initiate a review via a pull request, and pull request > by definition compares your working

I can’t really provide a doc, but i can describe what I believe to be the biggest problem. In a GH PR, comments are associated with commit hashes. If a commit hash ceases to exist, so do all comments associated with it. The comments are quite literally destroyed and irretrievable. What this means for LLVM is that everyone will have to completely stop using history rewriting operations. No

On Thu, Jun 25, 2020 at 1:12 AM Manuel Klimek <klimek at google.com> wrote: > Mehdi, Fangrui: are you willing to take on maintenance? > Sure, let's work out a transition plan offline! > > Otherwise, Shoaib, the cost is currently: > ~$300-350 / mo for sendgrid (300-350k emails / month) > ~$2k / mo for cloud (we currently run on 1 machine O.O, plus storage & >

Nope, it wasn't all reverted -- the llgo implementation remains deleted. There's been some confusion borne out of unfortunate naming -- only the file "llvm/tools/llvm-go/llvm-go.go" was reinstated. Despite its confusing name, this tool is *not* a go implementation, and has effectively nothing to do with llgo. It's only a tiny utility script used by the llvm build process for

Hello Devs, I am getting following error while connecting to review server. " A Troublesome Encounter! Woe! This request had its journey cut short by unexpected circumstances (Can Not Connect to MySQL)" Is anyone else facing this? Thanks [image: Inline image 1] -------------- next part -------------- An HTML attachment was scrubbed... URL:

"The llgo frontend has been removed for now, but may be resurrected in the future." Thoughts? -eric On Tue, Aug 25, 2020 at 2:18 PM Hans Wennborg via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Can someone add a mention about the llgo removal to the release notes? > > Thanks, > Hans > > On Fri, Feb 14, 2020 at 3:40 PM James Y Knight via llvm-dev >

Is the plan for LLDB to just adapt the code that is trying to follow the new code style or also the code using the LLDB code style? I’m in general in favor of moving LLDB to the LLVM code style because it makes the LLDB code that interfaces with Clang/LLVM less awkward to write (e.g. no more code style confusion when inheriting from a Clang classes inside the LLDB code base). But I think if we do