On 2018/5/3 11:44 PM, Jens Axboe wrote: > On 5/3/18 9:40 AM, Coly Li wrote: >> On 2018/5/3 10:34 PM, Jens Axboe wrote: >>> On 5/3/18 4:51 AM, Coly Li wrote: >>>> Hi Jens, >>>> >>>> I receive bug reports from partners for the bcache cache device failure >>>> handling patch set (which is just merged into 4.17-rc1). Fortunately we >>>> are still in 4.17 merge window, I suggest to have these fixes to go into >>>> 4.17 merge window too. >>> >> >> Hi Jens, >> >>> We're not, though. The merge window is from when 4.16 is released and >>> until 4.17-rc1 is tagged, so we're way beyond at this point. That doesn't >> >> I have more clean concept what a merge window is :-) > > The merge window is a cleanly defined concept, so there's not a lot of room > for interpretation :-) > >>> mean we can't take fixes, but this late in the cycle, they really have >>> to be fixes for regressions introduced in this merge window. Or simple >>> or serious enough that we should take them for this release, instead >>> of pushing them to the 4.18 merge window. >>> >> >> Maybe next time (if there is) I should say the fixes should go into this >> release, not merge window. Because the merge window is gone after rc1 >> released. > > Right, generally I'd recommend that you maintain two branches (or however > you want to organize it). One is for fixes that should go into the > current release. You can submit those anytime, just beware of the > limitations of those (as outlined above). The other should be for new > development or fixes that can wait, for the next release. The grunt > of these should be submitted by the time that -rc7 is tagged, so they > have at least a week in my tree before going upstream. > Copied, thanks for your suggestion, this is the way I take for now :-) Coly Li
