search for: pulled

Anthony, please pull the following changes since commit 6a4e17711442849bf2cc731ccddef5a2a2d92d29: ssh://xenbits.xen.org/home/sstabellini/git/qemu-dm.git xen_fixes_20130603

Hi all, Now that we're on GitHub, we can discuss about pull-requests. I'd like to propose to enable pull-request on GitHub, as a first step as an experimental channel alongside the existing methods for contributing to LLVM. This would allow to find workflow issues and address them, and also LLVM contributors in general to start getting familiar with pull-requests without committing to

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

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 Apr 21, 2017, at 12:54 PM, Jim Klimov wrote: > > Hi guys, I can't help noticing that many PRs seem good to go merged in NUT, so these improvements can either benefit the users instantly, or get exposed to more real-life testing and prove their worth or find issues to fix ;) > > Are there any objections to going on a merging-spree, and boost the morale of external contributors

On Mon, Jan 18, 2016 at 5:21 AM, Michael S. Tsirkin <mst at redhat.com> wrote: > Hi Linus, > Just making sure nothing's wrong with this pull request. > If there's an issue, pls let me know! It was just pulled because I wasn't 100% sure I wanted the extra indirection. Oh well, pulled now. One question: - the arch/sh/ part of the pacth looks dubious. Why does it do that #define smp_store_mb(var, value) __smp_store_mb(var, value) despite the commit log saying it's done by asm-generic?...

On Mon, Jan 18, 2016 at 5:21 AM, Michael S. Tsirkin <mst at redhat.com> wrote: > Hi Linus, > Just making sure nothing's wrong with this pull request. > If there's an issue, pls let me know! It was just pulled because I wasn't 100% sure I wanted the extra indirection. Oh well, pulled now. One question: - the arch/sh/ part of the pacth looks dubious. Why does it do that #define smp_store_mb(var, value) __smp_store_mb(var, value) despite the commit log saying it's done by asm-generic?...

...tools/virtio/ringtest/README | 2 + > > tools/virtio/ringtest/run-on-all.sh | 24 ++ > > 13 files changed, 1148 insertions(+), 10 deletions(-) > > How the heck did you generate that diffstat? The names should be > ordered, and are for me. > > Anyway, pulled. Just curious about how that thing happened. > > Linus That's because apparently diffstat obeys orderfile rules: [diff] renames = true orderfile = "/home/mst/.gitorderfile" $ cat .gitorderfile configure Makefile* *.json *.h *.c

...tools/virtio/ringtest/README | 2 + > > tools/virtio/ringtest/run-on-all.sh | 24 ++ > > 13 files changed, 1148 insertions(+), 10 deletions(-) > > How the heck did you generate that diffstat? The names should be > ordered, and are for me. > > Anyway, pulled. Just curious about how that thing happened. > > Linus That's because apparently diffstat obeys orderfile rules: [diff] renames = true orderfile = "/home/mst/.gitorderfile" $ cat .gitorderfile configure Makefile* *.json *.h *.c

Hi, From what I gather, OpenLDAP on Centos 5.x pulls LDAP changes from central LDAP server to a secondary LDAP server. So in other words, you can have your second LDAP server pull the db based on either; type=refreshOnly which mean the pull interval will happen when ever you specify or; type=refreshAndPersist which mean after a pull, keep the pipe open for any changes made. Now in

Hi, It has been observed that rsync push mode is much slower when compared to pull (On Identical scenarios). Building/receiving file list takes almost same time. But data transfer is much slower, whose transfer ratios are ranging from 1:3 to 1:5. On pull operation data transfer speed is consistently around 3.5 MB/Sec and it reached 10 MB/Sec. However, on push the maximum it could reach is

Hi all Thanks for your attention. CTDB manages NICs with event scripts. Virtual IP attaches on a NIC as a secondary IP. When noticing the NIC down, CTDB will pull it up. Does any one know how to disable the action? I do not want CTDB pull any NIC up. Does the command 'ctdb disablescript 10.interface' has any unexpected effect? Thanks.

Good morning, Dave. On Thu, Feb 24, 2011 at 4:17 AM, David A. Greene <greened at obbligato.org> wrote: > Do git repositories cloned from git-svn mirrors work properly?  For > example: > >                         svn >                          ^ >                          | >                          | >                          V >                       git-svn

NAKAMURA Takumi <geek4civic at gmail.com> writes: >> I don't think one can share commits from clone A to/from clone B without >> going through the parent git-svn repository.  Is that right?  I recall >> having read something about that somewhere. > > Maybe sure on git-svn's branch (eg. master). > "master" should never be pushed to

...ng down eth0 by command "ifdown eth0", CTDB will automatically pull eth0 up. Sometime it goes wrong. The virtual IP becomes primary IP, and origin primary IP turns into a secondary IP or just missing. If the origin primary IP is missing, I have to run "ifup eth0" though CTDB has pulled eth0 up. CTDB uses “ip link set eth0 up” to pull up a NIC. I suppose “ifdown/ifup” are not compatible with “ip link set”. -----邮件原件----- 发件人: Martin Schwenke [mailto:martin at meltin.net] 发送时间: 2016年9月14日 19:00 收件人: Weidong via samba 抄送: weidong 12656 (RD); xusangdi 11976 (RD) 主题: Re: [Samba] How...

Hi David, Any thoughts on either this pull request, or #129? https://github.com/networkupstools/nut/pull/128 https://github.com/networkupstools/nut/pull/129 Also note the mention of the new Python module here: https://github.com/george2/python-nut2/tree/development - Charles Begin forwarded message: > From: george2 <notifications at github.com> > Subject: [nut] PyNUT: Fix error

...nk some of contributors to the Clang received a notifications about some commits done in the past. > > I wanted to share my thoughts on why it might has happened. > > > > I think the commits from this PR https://github.com/llvm/llvm-project/pull/13were pulled by Phabricator (probably with aim to review GitHub pull requests in https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=AD-hZ9rLcmVgzhl1TFTAvKbX-nrgHD75y9sqN5zTEsg&s=KaCscc77Z-fBuYo2dCuykCeHg35yKQXRw...

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

The following includes vhost-net fixes - both in the experimental zero copy mode. Please pull for 3.1. Thanks!

The following includes vhost-net fixes - both in the experimental zero copy mode. Please pull for 3.1. Thanks!