On Thu, Feb 21, 2019 at 08:37:40AM +0800, Qu Wenruo wrote: > > > On 2019/2/21 上午2:25, David Sterba wrote: > > On Mon, Feb 18, 2019 at 01:27:41PM +0800, Qu Wenruo wrote: > >> Patchset can be fetched from github: > >> https://github.com/adam900710/linux/tree/write_time_tree_checker > >> Which is based on v5.0-rc1 tag. > > > > Please base the patches on something new, a recent rc is fine (rc6 or > > rc7 depends what you've tested). > > Any recommended workflow for different timing point? > E.g. always rebase to latest rc?
It depends on the phase of the development cycle, last released rc is a good default choice unless you have reasons not to use it. Think about it as "what does happen when this gets merged to the expected target branch?". If you send a fix for current master, then it's perfect to use the last rc in master, or base the patch on the branch that gets pulled there (eg. misc-4.20). > My current (and now is proven not proper) workflow is to stick with > -rc1, and cherry pick known fixes related to test. > This provides a stable base run to spot regression caused by my patches. You could use that as a reference point, but when the patches get merged, it's on a more recent codebase so it's better that you verify that it works on your side. The rc1 is not a very good base in general as there are so many changes in the whole kernel that need to stabilize.
