similar to: Enable Contributions Through Pull-request For LLVM

On Thu, Nov 7, 2019 at 3:09 AM Roman Lebedev via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Strong -1 personally. Likewise, for many of the same reasons detailed below. ~Aaron > * What is the endgoal? To fully kill phab and move to github pullrequests? > it might be best to discuss *that* first. (did i miss an RFC?) > * Separation of attention - does everyone who

On Fri, Nov 8, 2019 at 8:08 AM Philip Reames <listmail at philipreames.com> wrote: > Very strong -1 at the moment. I think we need to let some of the other > efforts (e.g. issues vs bugzilla) settle out first. > Sorry I really don’t see a relationship with issues, this seems entirely independent to me. I even actually see this as easier than issues. Weak -1 in general. I'm

I think that it's really important that we try to strike some balance here. Based on my experience, this thread, and offline conversations, two things seem clear to me: 1. Overall, Phabricator is a superior tool for managing code reviews and some related processes (although GitHub's tools certainly have some benefits, and both are getting better over time). 2. Not accepting GitHub PRs

-1 from me as well. GitHub UI feels extremely sluggish with large projects, forks feel like needless hurdles to jump over, especially for small patches - having to fork the entire monorepo, just to do a GitHub PR would be extremely cumbersome. Just recently I submitted a very tiny PR for PcapPlusPlus on GitHub which involved: 1). Forking the repository 2). Cloning the fork 3). Applying the patch

I don't intend to weigh in on either side, but just give a perspective on a few questions asked. >From an outsiders perspective, that list isn't what I'd typically describe as the workflow, since it makes "fork" and "branch" sound like difficult operations. This sounds akin to thinking that someone would reclone the svn repo before working on a new

On Thu, Nov 7, 2019 at 9:32 AM Finkel, Hal J. via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > On 11/7/19 10:13 AM, Jameson Nash wrote: > > I don't intend to weigh in on either side, but just give a perspective on > a few questions asked. > > From an outsiders perspective, that list isn't what I'd typically describe > as the workflow, since it makes

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

On Tue, Jan 14, 2020 at 09:56:53PM +0000, Renato Golin via cfe-dev wrote: > GitHub PR is the "de facto standard", everyone knows, the entry cost > is practically zero. The UI is lean and missing features, but the > large availability of tooling (either targeting GitHub directly or > plain git) makes up for a lot of it. Just like with the "Everyone knows git", I

-1 -- switch to PR's +1 -- Hal's compromise proposal (as long as I can continue to use Phab) I agree that the documentation could be better, but I don't see that as a justification for switching from a superior tool to an inferior one. Let's work on the documentation first, then if there's still a compelling reason to switch, do it then, I share most of the concerns already

Philip Reames via llvm-dev <llvm-dev at lists.llvm.org> writes: > Weak -1 in general.  I'm not strongly opposed, but I see very little > value in this migration and a lot of headache.  Others have explained > this well, so I'll mostly skip that.  I particular dislike the assumed > fork model; I work in patches, so that's a ton of overhead process wise.  Can you

Hi, I know there has been significant discussion about "moving" from Phabricator to GitHub reviews and pull requests, etc. I'm not suggesting that we do anything in terms of global LLVM policy. However, as a maintainer of libc++, I commit __a lot__ of other people's code for them. It would be a huge time saver for me if I could nicely suggest to contributors (not force them) 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 Fri, 10 Jan 2020 at 13:43, Nicolai Hähnle via llvm-dev <llvm-dev at lists.llvm.org> wrote: > It's worth pointing out that GitHub is not able to do this properly, > either. The problem on GitHub's side is that while a pull request can > contain multiple commits, one cannot properly review those commits > individually, and it is not at all possible to approve individual

On Thu, Jun 25, 2020 at 11:43 AM Nikita Popov via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On Thu, Jun 25, 2020 at 11:22 AM Zachary Turner via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> What this means for LLVM is that everyone will have to completely stop using history rewriting operations. No more rebase, squash, amend, etc. > > This is also incorrect. Most

I'm not sure the idea that enabling pull requests will make it easier for new contributors is fully thought out. Just because more people might be familiar with GitHub, doesn't mean it is superior. I've found the workflow on Phabricator to be really easy. I think many people agree that Phabricator is really good, I don't think we would want to get rid of Phabricator and while its

On Tue, Feb 25, 2020 at 4:19 AM Christian Kühnel via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi Louis, > > I think this is a good idea. We should start with some local experiments > where people are willing to try it and figure out how well that works and > what does not. Why not allow this for "not significant" changes? They are > merged without review

Uh-oh: Failed to publish: GitHub error 404 on POST https://api.github.com/repos/llvm/mlir-npcomp/pulls/42/reviews: Not Found (The llvm organization may need to authorize Reviewable as an accepted third party application.) Can an admin take the suggested action on the mlir-npcomp project in the LLVM org? I've followed the instructions in this help doc

Daniel Sanders via llvm-dev <llvm-dev at lists.llvm.org> writes: > Personally, I'd like us to drop the linear history requirement but I > know there's some strong opposition there. The main reason I'd like us > to accept non-linear history in conjunction with pull requests is that > it means that the commits that were tested (whether by the author or > by CI)

On Wed, Mar 4, 2020 at 8:14 AM Louis Dionne <ldionne at apple.com> wrote: > Mehdi, Chris & others, > > I guess I did not express the main reasons for wanting to switch over very > well in my original message. > You original message was about “ commit attribution”, but now it is all about testing? Instead of jumping to a solution (pull-request) why not expressing the

On Wed, Mar 4, 2020 at 9:42 AM Louis Dionne <ldionne at apple.com> wrote: > > > On Mar 4, 2020, at 12:13, Mehdi AMINI <joker.eph at gmail.com> wrote: > > > > On Wed, Mar 4, 2020 at 8:14 AM Louis Dionne <ldionne at apple.com> wrote: > >> Mehdi, Chris & others, >> >> I guess I did not express the main reasons for wanting to switch over