On Sat, Feb 29, 2020 at 09:00:43AM +0800, Qu Wenruo wrote: > > > On 2020/2/28 下午11:45, David Sterba wrote: > > On Wed, Feb 26, 2020 at 01:56:42PM +0800, Qu Wenruo wrote: > >> This branch can be fetched from github: > >> https://github.com/adam900710/linux/tree/backref_cache_new > > > > This is based on v5.6-rc1, you should base on something more recent. > > There are many non-trivial conflicts at patch 5 so I stopped there but > > if you and I like to get the pathes merged, the branch needs to be in a > > state where it's not that hard to apply the patches. > > Because it looks like current misc-next is not a good place to do proper > testing, and it's undergoing frequent updates. Well yes, that's the point and has been like that for a long time. It's a development base that should be reasonably stable, IOW I add patches there when the branch itself passes fstests and the to-be merged patches pass as well. For the 'reasonably stable' part, fixups and additional functional updates should be minimal but they happen as this is branch that more people start to test, unlike some random patchsets. > Thus I choose the latest rc when I started the development. Yes but you should also have rebased each week so the latest rc is still the latest one. > Currently the branch is only for review and my local testing, I just > want to make sure that everything works fine before rebasing them to > misc-next. Maybe I have missed you saying it's for review and independent testing, for cleanups this should make no difference once the branch is ported on top of current devel queue (misc-next). I still think that rebasing once a week on top of current rc+misc-next is feasible and should save time to all of us in the future. > Anyway, next time I'll mention the basis, and explicitly shows that I'll > do the rebase (and retest) if you want to try merge. Yes mentioning the patch base helps in case it's not something that others would expect, which in most cases is misc-next.
