> On Jun 23, 2023, at 8:16 AM, Jens Axboe <axboe@xxxxxxxxx> wrote: > > On 6/23/23 9:08?AM, Song Liu wrote: >> Hi Jens, >> >> I am so sorry for this problem. >> >>> On Jun 23, 2023, at 7:12 AM, Jens Axboe <axboe@xxxxxxxxx> wrote: >>> >>> On 6/22/23 11:48?PM, Song Liu wrote: >>>> Hi Jens, >>>> >>>> Please consider pulling the following changes for md-next on top of your >>>> for-6.5/block branch. The major changes are: >>>> >>>> 1. Deprecate bitmap file support, by Christoph Hellwig; >>>> 2. Fix deadlock with md sync thread, by Yu Kuai; >>>> 3. Refactor md io accounting, by Yu Kuai. >>> >>> This is quite a lot on the day that I prepare pull requests for the >>> merge window... I've said this many times before, but just to state this >>> in completeness, maybe it'll benefit others too: >>> >>> 1) Major changes for the next release should be sent to me _at least_ 1 >>> week prior to the merge window opening. That way it gets some decent >>> soak time in linux-next before heading upstream. >> >> I am aware of the rule. A couple reasons caused a late PR this time: > > Then please be explicit when sending out a pull request like this on why > it's late. Otherwise it just looks like a normal pull request, which it > is not. If your original pull request had any kind of explanation on why > so much is being sent so late, then we would not be having this followup > at all... Indeed! I should have explained the case in the first place. > >> 1. Set #1 and set #3 are relatively new, especially set #3, which was >> first sent earlier this week. Set #2 is older, but there was more >> discussions on it until recently. (It is still my fault not pushing >> on set #2 sooner). >> >> 2. I wasn't very sure whether there will be a rc8. The announcement for >> rc7 didn't state it clearly. (Shall I assume there is no rc8 unless >> Linus states it clearly?) >> >> 3. I was hoping to group more patches into one PR. I guess this was the >> biggest mistake, especially when it is close to the merge window. > > Most of the time Linus will be explicit about _maybe_ doing an -rc8, but > it doesn't really change the rule that I should have bigger stuff in the > week between rc6 and rc7. When -rc7 is cut, my for-next branches should > be basically baked and done at that point, and then post -rc7 just fixes > for existing code. If people stick to that rc6-7 timing, then it'll > always work, regardless of an -rc8 happening or not. > > Even when Linus has -rc8 musings in his later rc posts, it's not a given > that they will happen. Thanks for the explanation. I will get big things ready before rc7 in the future. > >>> 2) Minor fixes, either for major pulls that already went into my next >>> branch or just fixes in general, can be sent anytime and I'll shove >>> them into the appropriate branch. >>> >>> When bigger stuff gets sent this late, then I have two choices: reject >>> them and tell you to send it in for the next version, or setup a new >>> branch just for this so I can send it to Linus in a later pull in the >>> merge window. Neither of those two options are great - the first one >>> delays you by a release, the second one creates more churn and hassle >>> for me. >> >> I will prepare another PR with just fixes. >> >> Christoph, >> >> Please let me know if you need set #1 (deprecate file bitmap) to >> unblock other work. Otherwise, we will delay it until 6.6. > > I've done a for-6.5/block-late and put your stuff there, but it can be > dropped very easily. It doesn't really matter if Christoph's stuff can > get pushed, it's still a lot of commits late. So regardless of that, the > only real difference with a new PR would be that we'd drop some bits. > It'd still go into a late branch, as it is indeed late. Thanks for taking them to the late branch. If it is dropped, shall I 1. Delay bigger sets until 6.6; 2. Send fixes in a separate PR (after 6.5-rc1)? Thanks, Song
