From: Jens Axboe <axboe@kernel.dk>
To: Coly Li <i@coly.li>
Cc: linux-bcache@vger.kernel.org, linux-block@vger.kernel.org,
bcache@lists.ewheeler.net
Subject: Re: [PATCH 00/13] bcache: fixes and update for 4.14
Date: Wed, 6 Sep 2017 09:46:07 -0600 [thread overview]
Message-ID: <ffeb8364-a0ac-009c-5430-f047457d1272@kernel.dk> (raw)
In-Reply-To: <d2a5b042-a81d-71c4-1f8c-8fc6416ed363@coly.li>
On 09/06/2017 09:41 AM, Coly Li wrote:
> On 2017/9/6 下午10:20, Jens Axboe wrote:
>> On Wed, Sep 06 2017, Coly Li wrote:
>>> Hi Jens,
>>>
>>> Here are 12 patchs for bcache fixes and updates, most of them were posted
>>> by Eric Wheeler in 4.13 merge window, but delayed due to lack of code
>>> review.
>>
>> Next time, please send this _before_ the merge window opens. Not a huge
>> problem for this series, since it has been posted numerous times in the
>> past and already has good review coverage, but it really should have
>> been in linux-next for a week or two before heading upstream.
>>
> Hi Jens,
>
> Copied, send patches _before_ merge window opens.
>
> But could you please to give me a hint, how can I find when a specific
> merge window will open ? I search LKML, and see people send pull
> requests for 4.14 merge window, but I don't see any announcement for
> 4.14 merge window time slot.
The merge window opens when Linus releases the previous kernel. So you
have to try and keep track of when he expects to do that. That really
isn't that difficult - Linus always cuts a release on Sundays. We always
have 7 or 8 rc releases, so a good time to check is his mail on -rc6 or
-rc7 release, that usually gives a good indication of when he expects to
release the final.
To keep things simple, if you always have things ready when -rc7 is
released, then you are at least one week out from the merge window,
possibly two if we end up doing an -rc8. That means you don't have to
track anything, you know the exact date of when -rc7 is released since
Linus's schedule is usually reliable.
--
Jens Axboe
next prev parent reply other threads:[~2017-09-06 15:46 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-06 6:25 [PATCH 00/13] bcache: fixes and update for 4.14 Coly Li
2017-09-06 6:25 ` [PATCH 01/12] bcache: Fix leak of bdev reference Coly Li
2017-09-06 6:25 ` [PATCH 02/12] bcache: fix sequential large write IO bypass Coly Li
2017-09-06 6:25 ` [PATCH 03/12] bcache: do not subtract sectors_to_gc for bypassed IO Coly Li
2017-09-06 6:25 ` [PATCH 04/12] bcache: Don't reinvent the wheel but use existing llist API Coly Li
2017-09-26 4:38 ` Michael Lyle
2017-09-26 6:39 ` 박병철/선임연구원/SW Platform(연)AOT팀(byungchul.park@lge.com)
2017-09-26 7:09 ` Coly Li
2017-09-26 7:15 ` 박병철/선임연구원/SW Platform(연)AOT팀(byungchul.park@lge.com)
2017-09-26 7:22 ` Coly Li
2017-09-26 7:08 ` Coly Li
2017-09-26 7:16 ` 박병철/선임연구원/SW Platform(연)AOT팀(byungchul.park@lge.com)
2017-09-26 7:24 ` Coly Li
2017-09-26 7:46 ` Coly Li
2017-09-26 19:55 ` Michael Lyle
2017-09-06 6:25 ` [PATCH 05/12] bcache: gc does not work when triggering by manual command Coly Li
2017-09-06 6:25 ` [PATCH 06/12] bcache: correct cache_dirty_target in __update_writeback_rate() Coly Li
2017-09-06 6:25 ` [PATCH 07/12] bcache: Correct return value for sysfs attach errors Coly Li
2017-09-06 6:25 ` [PATCH 08/12] bcache: increase the number of open buckets Coly Li
2017-09-06 6:25 ` [PATCH 09/12] bcache: fix for gc and write-back race Coly Li
2017-09-06 6:26 ` [PATCH 10/12] bcache: silence static checker warning Coly Li
2017-09-06 6:26 ` [PATCH 11/12] bcache: Update continue_at() documentation Coly Li
2017-09-06 6:26 ` [PATCH 12/12] bcache: fix bch_hprint crash and improve output Coly Li
2017-09-06 14:20 ` [PATCH 00/13] bcache: fixes and update for 4.14 Jens Axboe
2017-09-06 15:41 ` Coly Li
2017-09-06 15:46 ` Jens Axboe [this message]
2017-09-06 17:38 ` Coly Li
2017-09-07 18:51 ` Eddie Chapman
2017-09-07 19:31 ` Jens Axboe
2017-09-07 19:01 ` Eddie Chapman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ffeb8364-a0ac-009c-5430-f047457d1272@kernel.dk \
--to=axboe@kernel.dk \
--cc=bcache@lists.ewheeler.net \
--cc=i@coly.li \
--cc=linux-bcache@vger.kernel.org \
--cc=linux-block@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox