Hello, Following recent events, I decided to improve (hopefully it will be an imporvement), how XFS integration flows. For a while, XFS integration follows a process where we stack patches on for-next for a few days (in a good moment a couple weeks), and let them cook there before sending them to Linus. This works but has a big down side. Patches for the next merge window are kept in my trees locally, and although I test them from time to time, they only hit linux-next late in the cycle, also, it's hard for others to know what is queued or not (and to develop work on top of that). The main change I'm going to do, is in for-next branch. Currently I push patches there only when I've selected which patches I'm going to send to Linus on the next batch, whether it's a -RC or the next merge window. I'll change it, by pushing to for-next everything that has been reviewed and smoke tested, whether it's for a -RC or next merge window. This will enable xfs patches to stay in linux-next as much as possible before they get sent to Linus. The biggest change here is that for-next will likely need to be rebased more often than today. But also patches will spend more time under testings in linux-next and everybody will have a more updated tree to work on. Also, I'm still thinking how to handle pull requests I receive. I try hard to not change the commit hashes from the PRs, so I'm still not sure how feasible it will be to keep the same hash ids from PRs giving more often than not I'll need to rebase the next merge tree on the top of fixes for the current -RC and in some cases, on top of other trees with dependencies. I'm sending this information now as if you have any concern, please let me know. By now, I'm creating a new branch named xfs-6.15-merge to aggregate everything I already have for 6.15, and later this week I'll be merging it into for-next Hopefully, for the majority of xfs tree users, this should be mostly transparent. Only those who watch the development really close may notice differences. Cheers, Carlos
