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... > 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. >> 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. -- Jens Axboe
