Ari Sundholm <a...@tuxera.com> writes: > On 07/09/2018 10:07 AM, Markus Armbruster wrote: >> Ari Sundholm <a...@tuxera.com> writes: >> >>> This was accidentally omitted. Thanks to Eric Blake for spotting this. >>> >>> Signed-off-by: Ari Sundholm <a...@tuxera.com> >>> --- >>> qapi/block-core.json | 2 ++ >>> 1 file changed, 2 insertions(+) >>> >>> diff --git a/qapi/block-core.json b/qapi/block-core.json >>> index 38b3125..62a92fa 100644 >>> --- a/qapi/block-core.json >>> +++ b/qapi/block-core.json >>> @@ -3057,6 +3057,8 @@ >>> # @log-sector-size: sector size used in logging writes to @file, >>> determines >>> # granularity of offsets and sizes of writes (default: >>> 512) >>> # >>> +# @log-append: append to an existing log (default: false) >>> +# >>> # @log-super-update-interval: interval of write requests after which the >>> log >>> # super block is updated to disk (default: >>> 4096) >>> # >> >> Applied to qapi-next. Thanks! >> > > Thanks. Does this mean that the patch be queued for 3.0 or should I > take some additional steps to ensure this?
When a maintainer (like me) accepts your patch, he also accepts resposibility to get it merged into master. The patch submitter (you) should not have to do anything to get that done. "Should" only because maintainers aren't infallible :) I keep tracking my own patches until they reach master. Pretty much always they just do. Only once in a great while I have to ask a maintainer what's up. In this case, your patch should be in my next QAPI pull request, and you should receive a copy.
