On Fri, May 29, 2020 at 08:39:32AM +1000, Dave Chinner wrote:
> On Wed, May 27, 2020 at 07:44:10PM -0700, Darrick J. Wong wrote:
> > On Thu, May 28, 2020 at 10:03:51AM +1000, Dave Chinner wrote:
> > > From my perspective, an update from for-next after the -rc6 update
> > > gets me all the stuff that will be in the next release. That's the
> > > major rebase for my work, and everything pulled in from for-next
> > > starts getting test coverage a couple of weeks out from the merge
> > > window. Once the merge window closes, another local update to the
> > > -rc1 kernel (which should be a no-op for all XFS work) then gets
> > > test coverage for the next release. -rc1 to -rc4 is when
> > > review/rework for whatever I want merged in -rc4/-rc6 would get
> > > posted to the list....
> >
> > <nod>
> >
> > My workflow is rather different -- I rebase my dev tree off the latest
> > rc every week, and when a series is ready I port it to a branch off of
> > for-next.
>
> I do actually update the base kernel quite frequently - usually
> every monday after a -rc is released. This is easy, and rarely
> causes rebase issues because all the XFS changes in the base tree
> have already been in the for-next tree. i.e. my typical weekly
> "rebase" is:
>
> git remote update
> for each git branch:
> guilt pop -a
> git reset --hard origin/master # latest Linus tree
> git merge linux-xfs/for-next
> <merge any dependencies>
> loop {
> guilt push -a
> <fix patch that doesn't apply>
> } until all patches applied
>
> If there's no significant change in for-next, then this is all easy
> and is done in a few minutes. But if there's substantial change to
> for-next, then the problems occur when pushing the patches back
> onto the stack...
>
> I've always based my dev work on the for-next branch (or equivalent
> dev tree tip) because that way I'm always testing the latest dev
> code from everyone else and I know my code works with it.
<nod>
> > Occasionally I'll port a refactoring from for-next into my
> > dev tree to keep the code bases similar.
>
> Yup, that's the "<merge any dependencies>" in the process above.
> i.e. someone has posted a cleanup patchset that's going to be merged
> into for-next before the work I'm doing. That's where all the recent
> problems have been coming from - the pain either occurs at the next
> for-next update, or I take it when it's clear it's going to be
> merged soon...
<nod> I guess the difference is that I don't generally merge for-next
wholesale into my dev tree, so that's probably why I didn't see quite as
much for-next-churn troubles. :/
--D
> Cheers,
>
> Dave.
> --
> Dave Chinner
> david@xxxxxxxxxxxxx
