similar to: Notes from GitHub Pull Requests round table

Displaying 20 results from an estimated 10000 matches similar to: "Notes from GitHub Pull Requests round table"

2020 Nov 19
2
Notes from GitHub Pull Requests round table
On 18/11/2020 17:36, Mike Edwards via llvm-dev wrote: > Hi Keith, > You should be able to access the notes here: > https://docs.google.com/document/d/1flP8TqS71x4KF6h98vZV3ctXADBD39_vjrXn_BQn4hQ/edit?usp=sharing > <https://docs.google.com/document/d/1flP8TqS71x4KF6h98vZV3ctXADBD39_vjrXn_BQn4hQ/edit?usp=sharing> > Let me know if you run into any issues. Thanks. There's
2020 Nov 18
0
Notes from GitHub Pull Requests round table
Hi Keith, You should be able to access the notes here: https://docs.google.com/document/d/1flP8TqS71x4KF6h98vZV3ctXADBD39_vjrXn_BQn4hQ/edit?usp=sharing Let me know if you run into any issues. Thanks, Mike On Mon, Nov 16, 2020 at 4:45 PM Keith Smiley via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I saw some other posts on this list about notes from the round tables at > the
2020 Nov 19
0
Notes from GitHub Pull Requests round table
On Thu, Nov 19, 2020 at 1:56 AM David Chisnall via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 18/11/2020 17:36, Mike Edwards via llvm-dev wrote: > > Hi Keith, > > You should be able to access the notes here: > > > https://docs.google.com/document/d/1flP8TqS71x4KF6h98vZV3ctXADBD39_vjrXn_BQn4hQ/edit?usp=sharing > > < >
2020 Jun 19
2
Phabricator Maintenance
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
2020 Jun 19
5
Phabricator Maintenance
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
2020 Jun 19
3
Phabricator Maintenance
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
2020 Jun 19
4
Phabricator Maintenance
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
2020 Jun 22
3
Phabricator Maintenance
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
2020 Jun 22
1
Phabricator Maintenance
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
2020 Jun 23
3
Phabricator Maintenance
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
2016 Aug 05
2
Pull requests: CJK words and Snippet generator
On Thu, Aug 4, 2016, at 15:08, James Aylett wrote: > On Wed, Aug 03, 2016 at 08:17:05PM +0200, rsto at paranoia.at wrote: > > I'll notify you when the CJK pull request passes Travis. > > That's great, thanks! Alright, after lots of fiddling with .travis.yml I finally made the pull request build on Travis' trusty image: https://github.com/xapian/xapian/pull/114 I have
2019 Apr 21
5
Close PRs on GitHub repo
There is already 10 PRs sent to GitHub repo. But they all are useless, in every PR people are being informed that they should send patches to http://reviews.llvm.org/
2020 Jan 22
2
Phabricator -> GitHub PRs?
> > In Github pull requests there is always a git commit that you can just >> feed to the build server. And you can be sure of what really gets merged. >> You review, build and test exactly the change that gets merged afterwards. >> > > How would that be true? Given that upstream keep changing during the > period of review? The commit is going to have to be rebased
2019 Mar 20
3
[lldb-dev] [GitHub] RFC: Enforcing no merge commit policy
On 03/20/2019 10:41 AM, Zachary Turner wrote: > > > On Tue, Mar 19, 2019 at 12:00 PM Tom Stellard via lldb-dev <lldb-dev at lists.llvm.org <mailto:lldb-dev at lists.llvm.org>> wrote: > > Hi, > > I would like to follow up on the previous thread[1], where there was a consensus > to disallow merge commits in the llvm github repository, and start a
2016 Aug 18
2
Pull requests: CJK words and Snippet generator
Hi, On Thu, Aug 11, 2016, at 13:19, rsto at paranoia.at wrote: > The CJK word segmentation and snippet pull requests both pass Travis > since middle/end of last week. Did you find time to look at them? just checking in if you found time to look at the PRs? It'd be nice to know a tentative timeline, so I can plan if to build next features on top of our local fork or the upstream PRs.
2020 Jan 23
2
Phabricator -> GitHub PRs?
On Wed, Jan 22, 2020 at 11:24 PM David Greene <greened at obbligato.org> wrote: > Christian Kühnel via llvm-dev <llvm-dev at lists.llvm.org> writes: > > >>> In Github pull requests there is always a git commit that you can just > >>> feed to the build server. And you can be sure of what really gets > merged. > >>> You review, build and test
2019 Mar 20
2
[cfe-dev] [lldb-dev] [GitHub] RFC: Enforcing no merge commit policy
It sounds like we need to get someone from the Foundation (chandlerc@, lattner@, tanya@, someone else?) to reach out to them offline about this. On Wed, Mar 20, 2019 at 11:23 AM Arthur O'Dwyer <arthur.j.odwyer at gmail.com> wrote: > On Wed, Mar 20, 2019 at 2:19 PM Tom Stellard via cfe-dev < > cfe-dev at lists.llvm.org> wrote: > >> On 03/20/2019 10:41 AM, Zachary
2020 Jan 08
5
Phabricator -> GitHub PRs?
Now that we're on GitHub, can we *please* move to GitHub PRs? As much as I hate git, I hate Phabricator/Archanist even more. They're super clunky and makes working in git that much worse. -bw -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200107/e47b7e36/attachment.html>
2015 Jul 09
2
boot... round 2
On Thu, 2015-07-09 at 06:56 +0000, William Kennington wrote: > Does fedora have gcc5 patches? I believe they applied some of the 5.2 > changes. I'm not an expert on the gcc package, but looking at the changelog it appears to be be following the upstream 5.x branch: * Thu Jun 18 2015 Jakub Jelinek <jakub at redhat.com> 5.1.1-4 - update from the 5 branch - fix C++ ICE in
2019 Jan 31
2
[cfe-dev] [Github] RFC: linear history vs merge commits
<paul.robinson at sony.com> writes: > Systems that I've seen will funnel all submitted PRs into a single queue > which *does* guarantee that the trial builds are against HEAD and there > are no "later commits" that can screw it up. If the trial build passes, > the PR goes in and becomes the new HEAD. The downside of a system like this is that when changes are