mbox

[PULL] VirtFS update

Message ID 871tzic9p3.fsf@linux.vnet.ibm.com
State New
Headers show

Pull-request

https://github.com/kvaneesh/qemu.git for-upstream

Message

Aneesh Kumar K.V Feb. 5, 2014, 7:14 a.m. UTC
Hi Anthony,

Please pull the below update for VirtFS

The following changes since commit 2f61120c10da9128357510debc8e66880cd2bfdc:

  Merge remote-tracking branch 'qmp-unstable/queue/qmp' into staging (2014-02-01 23:32:31 +0000)

are available in the git repository at:


  https://github.com/kvaneesh/qemu.git for-upstream

for you to fetch changes up to f8b7ee38b3ed4ec2da5cc0529cf0cf82c8589805:

  hw/9pfs: fix P9_STATS_GEN handling (2014-02-02 22:09:16 +0530)

----------------------------------------------------------------
Kirill A. Shutemov (4):
      hw/9pfs: fix error handing in local_ioc_getversion()
      hw/9pfs: handle undefined FS_IOC_GETVERSION case in handle_ioc_getversion()
      hw/9pfs: make get_st_gen() return ENOTTY error on special files
      hw/9pfs: fix P9_STATS_GEN handling

 hw/9pfs/cofile.c           |  4 ----
 hw/9pfs/virtio-9p-handle.c |  8 +++++++-
 hw/9pfs/virtio-9p-local.c  | 10 ++++++----
 hw/9pfs/virtio-9p-proxy.c  |  3 ++-
 hw/9pfs/virtio-9p.c        | 12 ++++++++++--
 5 files changed, 25 insertions(+), 12 deletions(-)

 -aneesh

Comments

Aneesh Kumar K.V Feb. 5, 2014, 7:58 a.m. UTC | #1
Adding the correct email address for Anthony.

-aneesh

"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> writes:

> Hi Anthony,
>
> Please pull the below update for VirtFS
>
> The following changes since commit 2f61120c10da9128357510debc8e66880cd2bfdc:
>
>   Merge remote-tracking branch 'qmp-unstable/queue/qmp' into staging (2014-02-01 23:32:31 +0000)
>
> are available in the git repository at:
>
>
>   https://github.com/kvaneesh/qemu.git for-upstream
>
> for you to fetch changes up to f8b7ee38b3ed4ec2da5cc0529cf0cf82c8589805:
>
>   hw/9pfs: fix P9_STATS_GEN handling (2014-02-02 22:09:16 +0530)
>
> ----------------------------------------------------------------
> Kirill A. Shutemov (4):
>       hw/9pfs: fix error handing in local_ioc_getversion()
>       hw/9pfs: handle undefined FS_IOC_GETVERSION case in handle_ioc_getversion()
>       hw/9pfs: make get_st_gen() return ENOTTY error on special files
>       hw/9pfs: fix P9_STATS_GEN handling
>
>  hw/9pfs/cofile.c           |  4 ----
>  hw/9pfs/virtio-9p-handle.c |  8 +++++++-
>  hw/9pfs/virtio-9p-local.c  | 10 ++++++----
>  hw/9pfs/virtio-9p-proxy.c  |  3 ++-
>  hw/9pfs/virtio-9p.c        | 12 ++++++++++--
>  5 files changed, 25 insertions(+), 12 deletions(-)
>
>  -aneesh
Peter Maydell Feb. 10, 2014, 6:48 p.m. UTC | #2
On 5 February 2014 07:14, Aneesh Kumar K.V
<aneesh.kumar@linux.vnet.ibm.com> wrote:
>
> Hi Anthony,
>
> Please pull the below update for VirtFS
>
> The following changes since commit 2f61120c10da9128357510debc8e66880cd2bfdc:
>
>   Merge remote-tracking branch 'qmp-unstable/queue/qmp' into staging (2014-02-01 23:32:31 +0000)
>
> are available in the git repository at:
>
>
>   https://github.com/kvaneesh/qemu.git for-upstream
>
> for you to fetch changes up to f8b7ee38b3ed4ec2da5cc0529cf0cf82c8589805:
>
>   hw/9pfs: fix P9_STATS_GEN handling (2014-02-02 22:09:16 +0530)

Applied, thanks.

-- PMM
Andreas Färber Feb. 10, 2014, 7:21 p.m. UTC | #3
Hi Aneesh,

Please remember to label the pull request [PULL 0/m] and to thread the
actual commits as [PULL n/m]. We had to adopt our scripts, too.

Peter, please either enforce those rules or drop them for all of us!

Thanks,
Andreas
Peter Maydell Feb. 10, 2014, 7:43 p.m. UTC | #4
On 10 February 2014 19:21, Andreas Färber <afaerber@suse.de> wrote:
> Please remember to label the pull request [PULL 0/m] and to thread the
> actual commits as [PULL n/m]. We had to adopt our scripts, too.
>
> Peter, please either enforce those rules or drop them for all of us!

My workflow for applying pull requests doesn't technically
require this or check for it, and so I'm not going to
"enforce" this, since I might well not notice (and in this
case didn't). The rule is not for my benefit when applying
pulls, but for people who might be CC'd on patches forming
part of a pull request and who would otherwise not be able
to tell whether they could reasonably ignore them.

As usual we should:
(a) document our best practice:
 http://wiki.qemu.org/Contribute/SubmitAPullRequest
(b) politely nudge people if they have not followed it
 (and anybody who is adversely affected should feel free
 to do that; I don't have any particular greater standing
 here than you do); since this is pretty much always simply
 an occasional contributor who wasn't aware of something,
 a gentle nudge should be sufficient
(c) be open to reconsidering our practices if on balance the
 burden turns out to be greater than the benefit. (In this
 case personally I think the rule is a useful one.)

It's inevitably the case that some of our process isn't
enforced by technical means and so there will be occasional
accidental violations; we should in general assume good
faith. I'm not going to punitively refuse to apply pull
requests simply because they don't meet every detail of
what we prefer to do (though of course I will and
already have refused pulls which fail on significant points
like lack of signoff or review).

thanks
-- PMM
Andreas Färber Feb. 10, 2014, 7:48 p.m. UTC | #5
Am 10.02.2014 20:43, schrieb Peter Maydell:
> On 10 February 2014 19:21, Andreas Färber <afaerber@suse.de> wrote:
>> Please remember to label the pull request [PULL 0/m] and to thread the
>> actual commits as [PULL n/m]. We had to adopt our scripts, too.
>>
>> Peter, please either enforce those rules or drop them for all of us!
> 
> My workflow for applying pull requests doesn't technically
> require this or check for it, and so I'm not going to
[snip]

Anthony said that his "patches" tool relies on the 0/x, and I thought
you were using the same...

Andreas
Peter Maydell Feb. 10, 2014, 7:51 p.m. UTC | #6
On 10 February 2014 19:48, Andreas Färber <afaerber@suse.de> wrote:
> Am 10.02.2014 20:43, schrieb Peter Maydell:
>> On 10 February 2014 19:21, Andreas Färber <afaerber@suse.de> wrote:
>>> Please remember to label the pull request [PULL 0/m] and to thread the
>>> actual commits as [PULL n/m]. We had to adopt our scripts, too.
>>>
>>> Peter, please either enforce those rules or drop them for all of us!
>>
>> My workflow for applying pull requests doesn't technically
>> require this or check for it, and so I'm not going to
> [snip]
>
> Anthony said that his "patches" tool relies on the 0/x, and I thought
> you were using the same...

I was, but since the patches db isn't currently updating I
wrote a script which drives git directly and just wants the
"repo-url branchname" bit from the cover letter (and I find
the cover letters by textual search for the magic words that
git puts in pull requests).

thanks
-- PMM